RE: XML Query Comments to XML Schema (1st part)

Ashok,

> -----Original Message-----
> From: petsa@us.ibm.com [mailto:petsa@us.ibm.com]
> Sent: Friday, May 19, 2000 1:52 PM
> To: Matthew Fuchs
> Cc: 'www-xml-schema-comments@w3.org'
> Subject: Re: XML Query Comments to XML Schema (1st part)
> 
> 
> Matt:
> Lets examine your suggestion below which does seem cleaner than
> the other 2 alternatives:
> 
> <authors>
>   <simpleAuthor>Serge Abiteboul</simpleAuthor>
>   <complexAuthor><first>Dan</first><last>Sucia</last>
> </authors>
> 
> First, the element types <simpleAuthor> and <complexAuthor> are
> based on complexTypes called simpleAuthor and complexAuthor
> derived from abstractAuthor.
> 
> Second, when Query and XPath etc want to find all authors what will
> they search for?  If they search on elementTypes then we need an
> elementType called author and the engines must be educated to
> know that <simpleAuthor> and <complexAuthor> can be substituted
> for <author>.  This is not difficult.  After all the engines 
> have to be
> changed in some way to take derived types into account and this is
> as good a way as any.
> 

Yes, query engines will need to be upgraded for xsdl, and I've already built
a few.  Potent stuff.

Regarding the case at hand, we certainly need both an author element and an
author type - one to be an exemplar and one to be a base class for the
exemplar:

<element name = "author" type = "author"/>
<element name = "simpleAuthor" type = "simpleAuthor" equivClass = "author"/>
<element name = "complexAuthor" type = "complexAuthor" equivClass =
"author"/>

and somewhere else:

<complexType name = "authors">
  <element ref = "author" maxOccurs = "*"/>
</complexType>

So, all in all, we need 6 definitions - 3 types and 3 elements - which
exactly mimic each other - not including the definition of authors, which
can be done in a variety of ways.

Now, if the author element/type is not abstract and the query mechanism
isn't polymorphic either for equivClass or type, then for xsl-type
processing you'd need a match expression for <author> with type author,
<author> with type simpleAuthor, <author> with type complexAuthor,
<simpleAuthor> with type simpleAuthor (after all, it could be refined), and
<complexAuthor> with type complexAuthor.  And this still wouldn't match any
of the other elements or typs that could show up there.  This clearly
doesn't scale.

What the matching mechanism should be is an interesting question which would
take some space to discuss.  Suffice it to say that we have two kinds of
polymorphism and each must be considered.  I'll give a raincheck on a longer
discussion.

> =============================
> 
> On your other comment re. equivalence classes, did you mean to
> suggest that the feature be removed?  I was going to suggest merely
> that any element type be allowable in an equivalence class regardless
> of parentage.  This does not make it a CS equivalence class but I
> think such a feature would be useful.  Currently, its not very useful.
> 

At the very least I think this term should be renamed - it is blatantly
incorrect and it's scarcely a minor feature.  Fortunately it was noticed by
a sympathetic reader.  However it is certainly a statement on the workgroup
that despite this, Henry and I _together_ could not convince the group to
change the name.

However, I consider both elements and equivClass as totally superfluous to
building a language with the desired behavior.

Matthew

Received on Tuesday, 23 May 2000 14:17:30 UTC