- From: Henry S. Thompson <ht@cogsci.ed.ac.uk>
- Date: 24 Jan 2003 10:41:02 +0000
- To: "Nikola" <nikola.stojanovic@acm.org>
- Cc: <www-xml-schema-comments@w3.org>
"Nikola" <nikola.stojanovic@acm.org> writes: > I have a question related to ID syntax and how XML Schema constraints it > usage in XML instance documents. I have searched archives, but couldn't find > any explanation (examples, ...) that justify this constrant in XML Schema. > Here is a simple schema and an instance document that uses > "urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a" as an example of an ID. <snip/> > My understanding of XML 1.0 > (http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Name) is that ID can have > ":" characters, but XML Schema (http://www.w3.org/TR/xmlschema-2/#ID) > restricts this by forbiding the usage of ":" character > (http://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-NCName). In this way > URN syntax is not allowed in XML Schema ID. > I suspect that this might be Namespace Recommendation issue It is indeed -- see [1], the last paragraph. There has been lengthy discussion about this, and the forthcoming publication of Namespaces 1.1 will clarify the terminology, but not in such as was as to suggest that Schema will chnge in this area. > but could (should) this XML Schema constraint be relaxed in the > future This is unlikely, in my opinion. > or there would be (is) a way to build upon XML Schema type hierarchy > and still have IDREF semantics checked by validators when ID needs > to be compliant to URN syntax? Absolutely -- use key/keyref, and declare your attributes to have whatever type you think appropriate (e.g. xs:anyURI plus a 'urn:uuid:[-0-9a-f]*' pattern). ht [1] http://www.w3.org/TR/1999/REC-xml-names-19990114/#Conformance -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh Half-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam]
Received on Friday, 24 January 2003 05:40:53 UTC