Cart
[Home] [By Thread] [By Date] [Recent Entries]
[Steve Newcomb:] > > (1) XML Namespaces do not provide a way for a single element to > > conform to an element type in each of several schemas. Therefore, > > there is no way for a single element to be recognized as > > conforming to both the X:Foo and the Y:Bar element types. [Paul Prescod:] > You would not say directly that the element conforms both to X:Foo and > Y:Bar. You would rather s(in the schema) that the two are equivalent: > > """Through the new mechanism of element equivalence classes, XML Schemas > provides a more powerful model supporting substitution of one named > element for another. Any global element declaration can serve as the > defining element, or exemplar, for an element equivalence class. Other > global element declarations, regardless of target namespace, can be > designated as members of the class defined by the exemplar. In a > suitably enabled content model, a reference to the exemplar validates > not just the exemplar itself, but elements corresponding to any member > of the equivalence class as well. """ [Steve Newcomb:] The above paragraph worries me because I find it so baffling. A business requirement for distributing control over industrial vocabularies is to be able to say, in a way that is machine processable and that can be used to cause instance validation to occur, "My new element type, "Garp," is both an X:Foo as declared in the X schema (over which I have no control whatsoever), and a Y:Bar in the Y schema (I don't control the Y schema either)." I need a way for the instances of all Garp elements to be understood in terms of, and to be validated against, the definition of Foo in the X schema, and Bar in the Y schema. Is the idea of "equivalence classes" that all of the constraints contributed by X:Foo and Y:Bar are fully (and automatically) inherited by Garp, and that therefore it's only necessary for instances to be validated against Garp, rather than against X:Foo and Y:Bar? If the passing of constraints to equivalence classes is automatic, can the declaration for element type "Garp" further constrain X:Foo's constraints and Y:Bar's constraints? This is also a business requirement for distributing control over industrial vocabularies. > > (2) XLink is now just attributes; the element type can be anything. > > This permits a single element to be recognized as an XLink and as > > whatever else it may be. (Whatever else it may be, it may still > > only be one element type in one single namespace, as far as I > > know.) This is a kind of sleight-of-hand: XLink elements are > > still XLink elements; we still expect certain combinations of > > attributes to appear in certain contexts and not in others. > > Theoretically XLink could use the equivalence class mechanism. So > yourlink would be defined as a "kind of" xlink. But I haven't tried it > so take that with a grain of salt. I'm confused. I thought equivalence classes pertained to elements. The current XLink draft doesn't define any element types. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@t... http://www.techno.com ftp.techno.com NEW ADDRESS effective May 1, 2000: voice: +1 972 359 8160 fax +1 972 359 0270 405 Flagler Court Allen Texas 75013-2821 USA *************************************************************************** This is xml-dev, the mailing list for XML developers. To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/ ***************************************************************************
|
