[sc34wg3] Part 4: Canonicalization

Kal Ahmed sc34wg3@isotopicmaps.org
22 Nov 2003 17:40:58 +0000


Thanks for your comments. My apologies for taking a while to get to

On Sun, 2003-11-16 at 19:42, Martin Bryan wrote:
> The following comments are made with respect to the 2003-10-22 version of
> Part 4:
> Introduction.
> Delete first sentence in last paragraph as it repeats information in
> penultimate paragraph.


> 4.1
> In second para change "set to the element" by "a reference to the element"

It is unclear, but I'm not sure that I like using the term "reference".
How about 

"The value of the [parent] property of an element information item must
always be the element or document information item of which the element
information item is a direct child."

> 4.2
> In first numbered item remove "only"


> Somewhere before items 3 and 4 you need to explain what "The empty set" is
> as there is no logical reason for having any property that cannot contain
> any value.

You are right, there does need to be an explanation. The reason for
specifying that these information item property values are "the empty
set" is that the XML Infoset distinguishes between a property being
"unknown" (i.e. having no value) and a property have a value that is the
empty set).

> Somewhere before items 5, 6 and 7 you need to explain why properties that
> can never contain a value are required.

Same thing here...

> NB. It is not intuitive that these properties are used for consitency, or
> whether or not there are circumstances in which they can be updated. This
> must be made explicit to readers and not left for them to understand after
> making a detailed study of the spec.

I agree with your point. I think that the document should make it clear
that the CXTM specification does not define *any* operations that modify
XML Infoset information items post-creation. I'm just not certain what
the best way to phrase that would be.

> 4.5
> The meaning of "a representation" in items 2 and 3 needs to be defined.
> (What if I decide to create a painting of them?)

Agreed. The definition should probably go in 4.1

> 4.9
> In what format does "The element information item" take: the XML
> representation in the topic map of the information item?

The value of the [owner element] property is the element information
item that the attribute information item belongs to (in this case it is
the element information item that represents the association role
information item).

Information items are not entities with any form of representation
defined by the specification. They are simply named entities with a
collection of properties.

The W3C XML Information Set Recommendation says:

"The terms "information set" and "information item" are similar in
meaning to the generic terms "tree" and "node", as they are used in
computing. However, the former terms are used in this specification to
reduce possible confusion with other specific data models. Information
items do not map one-to-one with the nodes of the DOM or the "tree" and
"nodes" of the XPath data model."

Does that make sense ? It does to me, but I want to be sure that it does
to other readers.

> 4.11
> In item 2 what form should the "string representation of the position of the
> topic information item" take? Why should an application not be able to
> represent this information by an IDREF to an ID assigned to the information?

It can't be the ID of the information item, because a topic information
item has no [ID] property and has no property that has a single value
that could be used like an ID.

However, once sorted in canonical order, all topic information items in
the [topics] property of the topic map information item have an integer
position in that list, and this can be used as the reference.

It should be clearer that this is what is meant.

How about adding an initial subclause (after 4.1)

A reference to a topic information item shall be the integer value of
the position of that topic information item in the canonically sorted
[topics] property value of the topic map information item. The integer
value of the position of the first topic information item in the sorted
list shall be 1. All integer values shall be encoded in the XML Infoset
as an unpadded, string representation of the integer using decimal

And then change 4.11 item 2 to:

2. [normalized value] A reference to the topic information item that is
the value of the [type] property.

Note that this relies on the reader understanding the clear distinction
between the word "reference" in the context of this specification and
any notion of "reference" in parts 2 or 3. If there is a better term to
use to make this absolutely clear, I am open to suggestions.

> 4.13
> In item 2.3.2 what form should the "string representation of the position of
> the topic information item" take? Why should an application not be able to
> represent this information by an IDREF to an ID assigned to the information?

See above - obviously all other uses of this form of words would be
changed along the lines that I outlined above.


Kal Ahmed, Techquila
Standards-based Information Management
e: kal@techquila.com
w: www.techquila.com
p: +44 7968 529531