[sc34wg3] Part 4: Canonicalization

[Kal Ahmed]

On Tue, 2003-11-25 at 08:01, Martin Bryan wrote:
>  Kal
> 
> Re earlier comments on 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."
> > >
> > > My problem with this is that it sounds as if the value of the property
> must
> > > be surround the element. I see this as
> [parent="<element>....</element>]. I
> > > used reference because what the property should contain is a pointer to
> the
> > > element, not the element itself.
> > >
> you wrote:
> 
> > Is that because of the phrase "element or document information item" ?
> > It should say "element information item or document information item",
> > the value is the element information item (or document information
> > item), not any serialised form of it.
> 
> No. It's "value of" that is giving me the problem. If the value "must ... be
> the ... information item" the question arises as to what form does the
> information item take. Is it its internal form, its external
> (interchangeable form) or is it simply a pointer to where the information is
> strored internally? I believe it is the latter in this case. Hence my use of
> the terms reference and pointer.
> 

The XML Information Set does not constrain how it is represented - the
specification does not have any concept of referece or pointer, it
simply talks about properties having values which *are* information
items (or sets of information items). It is an abstract data model, not
an implementation model. An XML Info Set implementation is free to
duplicate information items, or to use references. The only thing that
is important is that if an application asks the implementation for the
value of the parent property, it receives the element information item
that represents the parent element. Whether this is done by
dereferencing a pointer or returning a value is not constrained.

>From CXTM's point of view, this XML Information Set is being constructed
for the purpose of either direct comparison or (more commonly I would
suspect) for CXML serialization so that the canonical forms can be
string-compared. So I don't think that CXTM need be any more specific
about implementation of the XML Information Set than the XML Information
Set Recommendation is.

> (For the same reason I want position to be used specifically in 4.11 -
> because that is not a pointer, but a count into a specific internal list. I
> suspect that in many cases the reference in 4.1 will be a count into an
> internal list, but in this case we have not said how the list should be
> created as we have in 4.11. If you are happy with reference in 4.11 why are
> you not happy with it in 4.1?)
> 

There is a difference. In 4.11, position has to be used because it is
not a reference to an XML Information Set information item, but to a
Topic Maps Data Model information item. The whole of section 4 is about
a transformation of an instance of the TMDM model to an instance of the
XML Information Set model, hence the reference to a topic information
item must be serialized in some form that is representable in the XML
Info Set (in this case a string). In 4.1,  the [parent] property is an
XML Info Set property whose value *is* and XML Info Set information
item. In the transformation process described in section 4, the
application should already have generated that information item that
will be the value of the parent property so there is no conversion from
the TMDM to be performed.

Cheers,

Kal