[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xml-dev] Re: determining ID-ness in XML
Just realized that this is actually part of "XPath Requirements Version 2.0"
http://www.w3.org/TR/xpath20req
| 5.4Should Support Lookups Based on Schema Unique Constraints and Keys
|
| XML Schema: Datatypes supports named, multi-part keys.
| XPath 2.0 SHOULD support a mechanism for looking up the element to which a
| Schema key refers. Similar mechanisms already exist, such as the id()
function in XPath 1.0 and the key() function in XSLT.
--Nikita
----- Original Message -----
From: "Nikita Ogievetsky" <nogievet@cogx.com>
To: <xml-dev@lists.xml.org>
Sent: Monday, November 05, 2001 9:04 AM
Subject: Re: [xml-dev] Re: determining ID-ness in XML
> I am not a specialist in XML Schemas, but as I understand,
> XML Schema [1] introduces augmentation to XML's ID/IDREF mechanism
> by providing mechanism for defining keys.
> Unfortunately these keys were designed to be used only for validation
> purposes and are not available in XPath.
>
> XML Schema keys contribute to PSVI, so why not let them in XPath
> expressions?
>
> For example,
>
> <xs:key name="country">
> <xs:selector xpath="country"/>
> <xs:field xpath="code"/>
> </xs:key>
>
> Could be used:
> "key('country','ru')/capital"
>
> and
>
> <xs:key name="fullName">
> <xs:selector xpath="person"/><!--from [1]-->
> <xs:field xpath="forename"/>
> <xs:field xpath="surname"/>
> </xs:key>
>
> Could be used:
> "key('fullName','Nikita','Ogievetsky')/@email"
>
> As I very obscurely :-) mentioned in my earlier message [2]
> this would tremendously facilitate XSLT transformations:
>
> If key tables were cached along with DOM document,
> XSLT processor would not have to recreate xsl key tables
> every time a transformation to the same document is applied.
>
> The only problems with xs:key-s are
> 1) They always imply uniqueness and referential constraints
> 2) They are defined in context of element definitions, not the document
> itself.
> (I think, both should be allowed)
> So it should have actually been <xs:selector xpath=".//country"/>
> and <xs:selector xpath=".//person"/> in the examples above.
>
> Again, I am not a big specialist in XML Schemas, so please
> correct me if I am wrong.
>
> [1] http://www.w3.org/TR/xmlschema-1/#cIdentity-constraint_Definitions
> [2] http://lists.xml.org/archives/xml-dev/200110/msg01062.html
>
> --Nikita.
>
> ----- Original Message -----
> From: "Rick Jelliffe" <ricko@allette.com.au>
> To: <xml-dev@lists.xml.org>
> Sent: Monday, November 05, 2001 3:10 AM
> Subject: Re: [xml-dev] Re: determining ID-ness in XML
>
>
> > From: "Henry S. Thompson" <ht@cogsci.ed.ac.uk>
> >
> > > It's precisely because IDness is orthogonal to type-validity that
> > > xml:id is the _wrong_ solution -- it doesn't allow me to combine
> > > IDness with e.g. being an NMToken or CDATA or in integer or . . .
> >
> > Well then what about
> >
> > xml:id
> > xml:key
> >
> > where id is an ID and key can be any string?
> >
> > Then we can use our schema language to further constrain the datatype of
> > the xml:key (or xml:id) for each element as required. Or we can
> > constrain the datatype of the key according to the element which refers
> > to it (we can do that, can't we?)
> >
> > No-one has ever demonstrated (that I have seen) that ID is not
> > a really useful mechanism for many kinds of XML documents.
> > In many cases it is trivial to munge a text key into a useful ID,
> > and this separation of data values from IDs prevents potential
> > problems with duplicate keys which could not occur in tables
> > but could occur with trees (if the keys are also data values).
> >
> > Cheers
> > Rick Jelliffe
> >
> >
> >
> >
> >
> >
> >
> > -----------------------------------------------------------------
> > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> > initiative of OASIS <http://www.oasis-open.org>
> >
> > The list archives are at http://lists.xml.org/archives/xml-dev/
> >
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.xml.org/ob/adm.pl>
> >
> >
>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
>