Re: Data model spec issues

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/ Eric Johnson <eric@tibco.com> was heard to say:
| 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?

I've added definitions for the new types to section 8. The exact
disposition of this material among the specs has not been firmly
decided, but I'll make sure that the DM either defines them or points
explicitly to their definition.

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

This issues have been fixed by rewording the Notation section and
adding new material to Section 8, Atomic Values. These changes appear
in the 12 Nov draft.

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

The spec has been reworded to provide additional clarity. These changes
appear in the 12 Nov draft.

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

The spec has been reworded to avoid the term 'tuple'.

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

This section has been reworded.

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

This accessor has been removed.

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

I clarified this for the 12 Nov draft.

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

The PI target and value and the comment value are accessible with the
existing accessors.

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

Reworded for the 12 Nov draft.

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

I have added a comment. The example is intended to be
illustrative of the data model, but I am reluctant to further
complicate it by adding date time types. I'm not sure that in the
context of the example, they would really add value.

The element declaration accessor is no longer present in the 12 Nov draft.

                                        Be seeing you,
                                          norm

- -- 
Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQE/skTYOyltUcwYWjsRAuiDAKCdSgTLx7Uqu/CP2Pde2Bxe5JGSjwCeMMHa
x3JRSKOsY1I04qbGsr4JkrY=
=fm0O
-----END PGP SIGNATURE-----

Received on Thursday, 13 November 2003 20:17:56 UTC