xml-dev - Re: XLink a special case in the self-describing Web?

["Steven R. Newcomb" <srn@techno.com>]

[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@techno.com  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@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************