RE: Data model spec issues

Dear Eric.

Thanks for your comments. See below for some answers. I will leave the
rest to our capable data model editors.

Best regards
Michael

> -----Original Message-----
> From: Eric Johnson [mailto:eric@tibco.com]
> Sent: Wednesday, May 21, 2003 7:21 AM
> To: W3C - Query-Transform
> Subject: 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?

[Michael Rys] The xdt-types are defined in the F&O document.

> 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? 

[Michael Rys] This depends on how your query environment manages your
data model instances.

> In other words, how "global" is global meant
> in this context? 

[Michael Rys] Within the scope of the data model instances and schemata
that you can at most operate on at the same time. Note that since this
type name is never exposed, it can be left to the implementation.

> Must an anonymous type name conform to a valid NCName?

[Michael Rys] No.

> Or alternatively, must it explicitly NOT be a valid NCName? 
[Michael Rys] Neither.

> Should
> these be stuck in a standard namespace, so as to guarantee they won't
> conflict? 
[Michael Rys] Since they are not being exposed, there is no need for the
specification to say anything about their form. See the formal semantics
for an example. You can put them into a namespace, use a GUID, use a
SCUD, a random number....

> 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.

[Michael Rys] Since the name is not exposed and thus the format used by
an implementation not testable, any such definition would be vacuous and
not testable or enforceable. So why should the spec do it?

> 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?

[Michael Rys] Thanks for the comment. The tuple currently provides an
implementation abstraction for the existing xs:datetime types in order
to be able to provide the TZ preservation. Other comments have been made
on this and I personally tend to agree that the WG should take a closer
look at splitting the datetime types as we did for duration...
 
> 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 20:59:47 UTC