Re: Data model spec issues

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

/ Eric Johnson <eric@tibco.com> was heard to say:
| 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'll make sure there's a better normative reference.

| Section 2-
|
| Notation – in the paragraph immediately after the example, the term
| "Item" is used, but doesn't correspond to anything in the example.

That should be xdt:untypedAtomic; "item" is a holdover from a previous
draft.

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

I'll try to clean up that text.

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

I think that'll be fixed by the improved normative reference to
the xdt: types.

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

I'll attempt to clarify that text.

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

We discussed this issue at *great* length. I think the tuple approach
is the best we're going to get consensus on. I grant, however, that
the current text could be clearer. The tuple in question is purely an
implementation detail. It's never directly exposed so bears no
relationship to sequences. I'll work on clarifying that.

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

Yes, this text is a little broken. It'll be fixed in the next round.

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

The issue that created this accessor has been reopened. I'll try to
make sure the results of its (re-)closure are more clearly described.

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

I think that's understood. I'm afraid that introducing it would probably
only confuse the issues.

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

What do you mean by "characteristics"?

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

Point taken.

| 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'll try to extend the example for the next round.

                                        Be seeing you,
                                          norm

- -- 
Norman.Walsh@Sun.COM    | O for a Muse of fire, that would ascend / The
XML Standards Architect | brightest heaven of invention, / A kingdom
Web Tech. and Standards | for a stage, princes to act / And monarchs to
Sun Microsystems, Inc.  | behold the swelling scene!--William
                        | Shakespeare, Henry V
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE+32EhOyltUcwYWjsRAm5+AJ9EKnyYbYbWDyQaCRo0jX+0agKdgACfZWK1
QcBaMmDJVmnh75PfwrWJli0=
=vd78
-----END PGP SIGNATURE-----

Received on Thursday, 5 June 2003 11:26:46 UTC