Data model spec issues

Prodded by someone in my company, I finally took the time to read the 
data model spec (http://www.w3.org/TR/xpath-datamodel/).  I had a few 
thoughts, which I hope will be helpful.  I apologize in advance that 
I've not been following the mailing list until now, so some of my issues 
may be redundant with what others have already said.

xdt:untypedAtomic is only defined by inference, as near as I can tell. 
Shouldn't it be defined somewhere?  Is it, and I just missed it?

Section 2-

Notation – in the paragraph immediately after the example, the term 
"Item" is used, but doesn't correspond to anything in the example. 
Actually, I found the example confusing, employing the word "Node" to 
refer to both the concept of a node, and the category of a node, so far 
as I could tell.

Spec uses the xdt prefix without defining it anywhere that I could find. 
It first shows up in the example here.

Section 3.4 -

anonymous type names - "globally unique" - this sounds suspiciously like 
a GUID or UUID. Does this need to be unique for all time, or merely the 
duration of the processing? In other words, how "global" is global meant 
in this context? Must an anonymous type name conform to a valid NCName? 
Or alternatively, must it explicitly NOT be a valid NCName?  Should 
these be stuck in a standard namespace, so as to guarantee they won't 
conflict?  Or alternately, should the requirement be that the namespace 
of the anonymous type be in the same namespace as its first 
non-anonymous ancestor?  I understand the desire to name the otherwise 
anonymous types, but tightening up the definition here could be 
extraordinarily useful downstream, or at least help clarify intent.

Section 3.6.1 – I found that the use of "tuple" here confuses matters 
for me greatly, in that sequences cannot hold tuples, only atomic values 
or nodes. Perhaps what is really being done here is the definition of an 
alternative simple type that represents date time values? If introducing 
an xdt:untypedAtomic, why not just introduce a new pair of types for 
dateTimes with/without timezones to work around the issue?

Section 4.1.1 – dm:base-uri

The three paragraphs confused me with the first few readings, especially 
with regard to empty versus non-empty behavior. I get the idea, but it 
seems contradictory to first say that something is empty, and then to 
say if it is empty, it takes the value of its parent, of course, that is 
not what it is saying, but that is how I read it first.  Additional 
insertions of the appropriate "accessor" or "property" term in relation 
to "base-uri" would help here.

Section 4.3.2 - the definition of the dm:element-declaration() accessor 
is confusing. Some context as to what point this serves, as well as an 
example would have helped me.  I've read this several times, and I still 
don't get it.  Is there any way to define this without referencing yet 
another external specification?  Also, the sentence before the 
definition reads "One additional accessors is defined on element 
nodes:", but "accessors" should not be plural.

4.5 - Namespaces - does the reserved "xml" prefix need mentioning here, 
or is that understood?

4.6, 4.7 - does it make sense to have accessor functions for the 
specific characteristics of comments and PIs?

Section 6: Says "Sequences are 'flat', they may not contain other 
sequences," and immediately thereafter, "An important characteristic of 
the data model is that there is no distinction between an item (a node 
or an atomic value) and a singleton sequence containing that item. An 
item is equivalent to a singleton sequence containing that item and vice 
versa." These two statements are somewhat contradictory, in that if a 
single item can be considered a sequence of one item, then a sequence 
can implicitly contain a sequence of sequences with only one item. I 
understand what is meant, but think the wording could be more precise.

The section D Example should include a comment. Given the difficulties 
with dateTime, perhaps one or two of those could be thrown in?  I also 
didn't find any examples of the dm:element-declaration() accessor.

-Eric Johnson

Received on Wednesday, 21 May 2003 10:23:59 UTC