[sc34wg3] CXTM: More Issues

[Lars Marius Garshol]

* Lars Heuer
>
> 3.5 Constructing a representation of a topic item
> -------------------------------------------------
> 2.6.3.2.4.
> """
> The position of the reified association role item [...]
> """
>
> "reified" should be dropped from that sentence.

It should indeed. Now dropped in my copy.

> 3.11 Constructing a representation of the [reifier] property
> ------------------------------------------------------------
> """
> If the [reifier] property of an information item is null it is
> represented by the empty set. Otherwise it is represented as a set
> containing an attribute information item with the following  
> properties:
> """
>
> I stumbled over the term "set".

The XML Information Set is pretty clear that the value has to be a set:

   [attributes] An unordered set of attribute information items, one for
   each of the attributes (specified or defaulted from the DTD) of this
   element. Namespace declarations do not appear in this set. If the
   element has no attributes, this set has no members.

Note the last sentence, especially, which seems to rule out "No  
Value" (the XML Infoset version of "null").

So formally, the ", if any" suggestion is not entirely correct. The  
same goes for the "null" suggestion.

I agree this isn't terribly pretty, but I'm not sure I see any better  
alternatives.

> Generally: The rules 3.4 - 3.10 mention
>
>    """
>    A representation of the [item identifiers] property, if any
>    """
>
> but the ", if any" seems to be superfluous because rule 3.14 states:  
> [...]

It could be seen as superfluous. If you were very strict you could see  
it as necessary, though, since if you say "A representation of the  
[item identifiers] property" there had better *be* a representation.

> BTW, to be consistent with the whole spec., 3.14. should be changed to
>
>    "[...] is the empty set [...]"
>
> maybe.

Unfortunately, no. We're in the middle of a list of element items  
here, we can't suddenly insert an empty set in that list.

Again, my inclination is to leave this alone.

> 4.5 Comparison Order for Locators
> ---------------------------------
> """
> Locators are compared in the same way as strings (see 4.3).
> """
>
> I assume, the *normalized* locator value is compared? Since the rules
> 3.3 - 3.24 are applied first? Maybe this should be made more explict?

Yes, it definitely should! Very good point. Now updated in my copy.

--Lars M.