W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > April to June 2000

Re: Simplifying XML Schema

From: Philip Wadler <wadler@research.bell-labs.com>
Date: Tue, 30 May 2000 18:01:53 -0400
Message-Id: <200005302201.SAA3091246@nslocum.cs.bell-labs.com>
To: petsa@us.ibm.com
cc: www-xml-schema-comments@w3.org

Thanks for your message, sorry to be so long in replying (all free
time has gone to hammering out the algebra).

You suggest that xsi:type might be useful in data integration.
(In fact, the same point had occurred to me, so I am softening
a little with regard to xsi:type.)  However, I'm confused by one
thing.  Here's the last example you give:

    <author xsi:type='firstAuthor'>Peter Buneman</author>
    <author xsi:type='secondAuthor'><first>Dan</first><last>Suciu</last><author>

Does this work in Schema?  I thought that Schema disallowed two
sibling elements to have the same name but different types.

Cheers,  -- P

> Phil:
> I'm trying to understand your concern with xsi:type and I must confess
> I'm having rather a difficult time of it.  So let me try and spell out the
> syntactic options.  Lets use the example Jerome had started re. two
> kinds of author elements.  Assume there is an abstract author type
> and from it we define a firstAuthor type and a secondAuthor type.  We then
> define firstAuthor and secondAuthor elements corresponding to the
> types.  You would like to see a syntax like:
>   <authors>
>      <author>Peter Buneman</author>
>      <author><first>Dan</first><last>Suciu</last><author>
>   <authors>
> As I discussed in an earlier e-mail this makes life very difficult for the
> validator.  It hits an <author> tag and knows its contents will be one of
> the subtypes
> derived from the abstract author type but does not know which one. So
> it has to search thru the types derived from author to find which subtype
> the
> specific author info matches.  This is expensive and we did not want the
> performance hit.
> As you suggested, we could also say:
>  <authors>
>      <author>
>          <firstAuthor>Peter Buneman</firstAuthor>
>      </author>
>      <author>
>          <secondAuthor>
>               <first>Dan</first><last>Suciu</last><author>
>          </secondAuthor>
>   <authors>
> I have no great problem with this.  I don't like the extra level of nesting
>  but
> that's a matter of taste.   You could also say:
>  <authors>
>      <firstAuthor>Peter Buneman</firstAuthor>
>      <secondAuthor><first>Dan</first><last>Suciu</last><secondAuthor>
>   <authors>
> Again. I have no problem with this.  The same information is conveyed.
> The argument against this is that when we write a query to find author's
> we will need to be able to educate the query engine to realise that
> fisrtAuthor and secondAuthor can be substituted for author.  This is a
> problem but I am not sure its a showstopper.
> Then you could say as the current draft does:
>  <authors>
>    <author xsi:type='firstAuthor'>Peter Buneman</author>
>    <author xsi:type='secondAuthor'><first>Dan</first><last>Suciu</last><author>
>   <authors>
> To my mind this conveys exactly the same information as the above two
> forms.  Just the syntax is different.  You have to look at the special
> attribute
> to tell the exact type but I don't see a fundamental difference.
> This form does have the advanatge that when you go to look for authors
> you just have to look for <author> tags.
> In fact, this was a factor in our picking the above form.  We were thinking
> about query :-)
> All the best, Ashok
Received on Tuesday, 30 May 2000 18:02:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:08:47 UTC