- From: Perry A. Caro <caro@Adobe.COM>
- Date: Wed, 16 Feb 2000 18:26:48 -0800
- To: Dan Connolly <connolly@w3.org>
- CC: www-rdf-interest@w3.org
Dan Connolly wrote: > The schema spec provides an answer of sorts: > > "we observe that > [XPointer] provides a mechanism which maps well onto our notion of > symbol spaces. > An fragment identifier of the form > #xpointer(schema/element[@name="person"]) will > uniquely identify the element declaration with name person, and similar > fragment > identifiers can obviously be constructed for the other top-level symbol > spaces." > http://www.w3.org/TR/1999/WD-xmlschema-1-19991217/#ref-schema > > Is that good enough? One immediate objection to using XPointer is the many-to-one nature of XPath. I believe most, if not all of us want the type URI to just be a unique ID, i.e., a particular string of characters that we can do reliable binary comparison or table lookup with. I'm not up on XPointer, but I am up on XPath which XPointer is built on, and XPath allows multiple equivalent expressions. Unless XPointer or the XML Schema usage of XPointer requires some sort of canonical XPath, processing overhead could be a pain. For example, all of these are equivalent (would evaluate to the same target): #xpointer(schema/element[@name="person"]) #xpointer(schema / element [ @name = 'person' ]) #xpointer(child::schema/child::element[attribute::name="person"]) #xpointer(schema/child::element[@name='person']) It's bad enough that we have to canonicalize arbitrary URI's (for whitespace and quote chars, as in the second example above), but XPath adds more ways to skin the same cat. Don't get me wrong: XPath is a great tool. I just don't want my stable unique ID's to be based on it. Perry
Received on Wednesday, 16 February 2000 21:28:01 UTC