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

RE: primary key elements, searchable elements, and element relati onships proposal

From: Brian H. Dunford-Shore <brian@gpc.wustl.edu>
Date: Tue, 18 May 1999 10:45:36 -0500
Message-ID: <29047528DFD1D211933F00609793730E343E@sos.wustl.edu>
To: "'petsa@us.ibm.com'" <petsa@us.ibm.com>, "Brian H. Dunford-Shore" <brian@gpc.wustl.edu>
Cc: "'Www-Xml-Schema-Comments@W3.Org'" <Www-Xml-Schema-Comments@w3.org>
On Thursday, May 13, 1999 8:18 AM, petsa@us.ibm.com [SMTP:petsa@us.ibm.com]
wrote:
> Brian:
> Thanks for your comments.  Keys and uniqueness have been on our minds.
> The reason you don't see anything about them in the draft is that we've
not
> decided what to do about them.  Below is my current thinking on the
subject.
> This does not mean that the WG will agree and this will find its way into
the
> spec but its gives us a position to discuss and debate.
> 

> 3) Multi-part keys are more problematic.  Clearly, they are a property of
> the parent element and must be declared there as your example shows.
> The syntax you propose seems reasonable but you also need to define
> foreign key relationships.
> 

Actually, foreign key relationships are defined implicitly in my example.
If the elementTypeRef does not have a 'primary' attribute which is true,
then it is a foreign key relationship to an elementType defined elsewhere or
to an elementTypeRef which does have a 'primary' attribute which is true.
It might be appropriate to have an 'foreign' attribute which explicitly
signals that the elementTypeRef is meant to be  part of a foreign key
relationship.

The underlying assumption here is that elementTypeRef's which refer to the
same elementType are implicitly setting relations between the elements.
Codifying this in the standard in some way (even if no new attributes or
keywords are added) would allow software to infer these relationships from
the way that elementType versus elementTypeRef's are used.

> 4) My instinct is not to specify anything having to do with search.  This
is
> because the best search strategy depends on how the document is stored
> and not some intrinsic property of the document.
> 

The possible data in a document does make the construction of certain types
of indexes to search the document possible or impossible.  If a certain
element, or combination of elements is guaranteed to be unique within the
document (or any possible document which satisfies the XML schema), then a
different type of index strategy may be employed which otherwise would not
be possible.

> 
> Regards, Ashok
> 
> 

My main concern at this stage, is that the underlying assumption about
elementTypeRef's which I stated above be allowed to hold in some form.  If
it does, then some level of relationships between elements may be inferred
using the current working draft and primary/foreign key relationships do not
require large changes/additions to the XML Schema standard and could
therefore, hopefully, be considered for incorporation fairly soon.

Thank you very much for your comments and work.

Brian

________________________________________________________________________
|  Brian H. Dunford-Shore              |  Campus Box 8036                |
|  Institute for Biomedical Computing  |  Phone: (314) 362-2944          |
|  Washington University in St. Louis  |  Fax:   (314) 362-0234          |
|  700 South Euclid Avenue             |  Email: brian@ibc.wustl.edu.us  |
|  Saint Louis,  Missouri 63110        |                                 |
======================================================


> Also perhaps desirable would be to be able to indicate which elements
> comprise a good set for searching.  An attribute for this might
> indicate what type of search this is good for (unique hash, keyword,
> etc.).
> 
> Relationships between elements (primary/foreign key relationships) can
> be implemented by assuming that if an elementType definition appears
> within the definition of another elementType definition, then it is
> the primary key element, otherwise, the new 'primary' attribute of
> elementTypeRef records this information.  Primary key relationships
> are cumulative, such that a new element added to the primary key makes
> the element which contains it the parent element.  (In the example
> below, element table1 is the parent of element table2 and element
> table2 is the parent of element table3).
> 
> 
> Here is the XML Schema definition (with changes to elementTypeRef and
> compositor):
> 
> <!-- elementTypeRef element type -->
>   <elementType name="elementTypeRef">
>     <archetypeRef name="reference"/>
>     <attrGroupRef name="occurrence"/>
>     <attrDecl name="primary">
>       <datatypeRef name="boolean">
>         <default>true</default>
>       </datatypeRef>
>     </attrDecl>
>   </elementType>
> 
> 
> 
>   <archetype name="compositor">
>     <elementTypeRef name="key" minOccur="0"/>
>     <elementTypeRef name="search" minOccur="0"/>
>     <choice minOccur="2" maxOccur="*">
>       <modelGroupRef name="modelElt"/>
>       <elementTypeRef name="elementType"/>
>     </choice>
>     <attrGroupRef name="occurrence"/>
>   </archetype>
> 
>   <archetype name="tuple">
>     <elementTypeRef name="elementTypeRef" maxOccur="*"/>
>   </archetype>
> 
>   <elementType name="key">
>     <archetypeRef name="tuple"/>
>   </elementType>
> 
>   <elementType name="search">
>     <archetypeRef name="tuple"/>
>   </elementType>
> 
> 
> 
> Example:
> 
> <elementType name="table1">
>      <sequence>
>           <key name="table1Primary">
>                <elementTypeRef name="field1"/>
>                <elementTypeRef name="field2"/>
>           </key>
>           <search type="unique">
>                <elementTypeRef name="field1"/>
>                <elementTypeRef name="field2"/>
>           </search>
>           <elementType name="field1">
>                <datatypeRef name='dt:numeric'>
>                     <precision>8</precision>
>                     <scale>2</scale>
>                </datatypeRef>
>           </elementType>
>           <elementTypeRef name="field2" primary="true"/>
>      </sequence>
> </elementType>
> 
> <elementType name="field2">
>      <datatypeRef name='dt:dateTime'/>
> </elementType>
> 
> <elementType name="table2">
>      <sequence>
>           <key name="table2Primary">
>                <elementTypeRef name="field1"/>
>                <elementTypeRef name="field2"/>
>                <elementTypeRef name="field3"/>
>           </key>
>           <search type="unique">
>                <elementTypeRef name="field1"/>
>                <elementTypeRef name="field2"/>
>                <elementTypeRef name="field3"/>
>           </search>
>           <elementTypeRef name="field1"/>
>           <elementTypeRef name="field2"/>
>           <elementType name="field3">
>                <datatypeRef name='dt:string'>
>                     <length>10</length>
>                </datatypeRef>
>           </elementType>
>      </sequence>
> </elementType>
> 
> 
> <elementType name="table3">
>      <sequence>
>           <key name="table2Primary">
>                <elementTypeRef name="field1"/>
>                <elementTypeRef name="field2"/>
>                <elementTypeRef name="field3"/>
>           </key>
>           <search type="unique">
>                <elementTypeRef name="field1"/>
>                <elementTypeRef name="field2"/>
>                <elementTypeRef name="field3"/>
>           </search>
>           <elementTypeRef name="field1"/>
>           <elementTypeRef name="field2"/>
>           <elementTypeRef name="field3"/>
>           <elementTypeRef name="field4">
>                <datatypeRef name='dt:string'>
>                     <length>10</length>
>                </datatypeRef>
>           </elementType>
>      </sequence>
> </elementType>
> 
Received on Tuesday, 18 May 1999 11:45:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 18:12:46 GMT