[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xml-dev] Re: determining ID-ness in XML
- From: Nikita Ogievetsky <nogievet@cogx.com>
- To: xml-dev@lists.xml.org
- Date: Mon, 05 Nov 2001 09:04:05 -0800
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>
>
>