[sc34wg3] Comments on CXTM (N0454)

[Lars Marius Garshol]

--- General

This looks like it is implementable now. It would be interesting to
hear whether the editor would encourage implementors to go ahead, or
whether it is still better to wait for a more stable draft.

Also, maybe describing default values for XML Infoset properties
(based on type) in a single place could be done to slim down the
document? That might help with another problem as well: not all
properties are given defined values everywhere.

Using [] to denote text to be added, and <> to denote text to be
deleted.


--- Introduction

4th para: "comparison of their canonical serialization[s]."

Beginning of 5th para: do we want to make clear some of the properties
of the canonical sort order here by adding adjectives? Like
"consistent"?

5th para: "sort order for any set <of> of information items"


--- 1. Scope

"an algorithm for the canonicalization of <an> instance[s] of the"


--- 3.2 Information Type and Basic Type Sort Order

The heading should read "Information item and fundamental type sort
order". (We changed the term "basic type" to "fundamental type" in the
last TMDM draft.)

"4. Variant <name>"

Null should be written in titlecase as in the TMDM.


--- 3.3 Comparison of String Property Values

Here all that is needed is an ordering based on the sequence of scalar
values that make up the strings. These values are numbers and can be
treated as such for the purposes of sorting. (We don't care about i18n
of sorting here, we just need consistency.)


--- 3.6 Canonical Sort Order For Topic Items

Item 2 should read "subject identifiers", not "subject indicators".


--- 3.7 Canonical Sort Order For Topic Name Information Items

In TMDM items of particular types are always named as "foo items",
rather than "foo information items". Following the same convention
here might shorten some of the longer headings. The same applies
throughout the text.

The parent-required issue is now resolved: parents are required
throughout TMDM.


--- 4.2 CXTM Document Information Item

We should probably look at what the consequences of setting
[standalone] to "No value" and [all declarations processed] to false
are.


--- 4.3

No namespace URI is given. Should one be, or should the property be
given an empty value of some sort? (Personally I don't really know.
It may be easier to leave this out, and it's not clear that there's
any use for it.)


--- 4.4

Instead of saying "the foo information items of the [bar] property"
maybe it would be better to say "the foo items *in* the [bar]
property". At least it would be more consistent with the TMDM.

Throughout the text reads "An empty list", but "the empty set". Like
all empty sets, all empty lists are alike, so... :-)

Also, the element type "subjectAddress" is used to represent the
[subject locator] property. This should be changed.


--- 4.5

Here we refer to ISO 10646 character codes instead of Unicode scalar
values as does TMDM. I realize the Infoset uses this terminology, but
USV is a) consistent with TMDM, b) more accurate, and c) we can be
consistent and reference Unicode instead of ISO 10646 everywhere.


--- 4.6

Typo: "represnted"

Constructing the [children] of the "value" element the [parent]
property is set, but as it is not set anywhere else that seems a bit
strange. Should be consistent, I think.


--- 4.9

The [role playing topic] property has been renamed to [role player].

Also, the topicref attribute should probably be moved to a separate
section in order to shorten the document and make it more readable.

Should it be named "topicRef" for consistency with XTM?

"The boolean value true" is not the same phrase used elsewhere. I'd
think "true" would do.


--- 4.10

Locators must be relativized before they are written out, or the
result of canonicalization will depend on where the input topic map
was loaded from.

This also applies to locator ordering, actually...

The "address" property of locator items is actually called
"reference".

Typo: "reprepresents".


--- 4.11

The second property is given as "[normalized value*d*]".


--- 4.13

[normalized valued] recurs here.


--- 4.15

IMHO having a reused clause for this is much better than repeating
this prose several places.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >