[sc34wg3] CXTM Draft Requirements available for review

[Kal Ahmed]

Hi Lars Marius,

Thanks for these comments! See my comments on your comments below.

As a point of order, is the version now on the website considered to be
fixed? In other words can I make some of the editorial changes that I
have been advised of or does that now have to wait for the end of the
review period for this document ?


On Fri, 2003-07-04 at 12:06, Lars Marius Garshol wrote:
> * Kal Ahmed
> |
> | The first draft of the requirements for ISO 13250-4, Canonical XTM is
> | now available for review and comment at [...]
> 
> Excellent! Great work! Here's my review.
> 
> --- History
> 
<snip/>
> We may not want to include all of this, but here the history is,
> anyway.
> 
It might be edited ever so slightly :) What I thought was important was
to capture references to the ISO documents which preceeded this one.

> 
> --- 2.1 
> 
> This doesn't specify what canonicalization actually is, and what the
> implicit requirement on any canonicalization algorithm must be. That
> is, it doesn't say that what it's supposed to do is to "produce
> byte-by-byte identical serializations for any two logically equivalent
> data model instances".
> 
> It also doesn't say that the purpose is primarily to support automated
> conformance testing, and secondarily to support automated quality
> assurance for those developing topic map engines.
> 

Point taken. I'll add a form of words for this

> Re "suite of conformance tests", I guess it is appropriate to mention
> OASIS here and say that ISO does not intend to do this. I realize you
> say this later, but isn't this a better place to do it?
> 

Its probably enough to say what CXTM is intended to do. And not to cover
what it is not intended to do (i.e. specify conformance test suites)
here. In other words I think that defining what canonicalization is and
the purpose of CXTM should replace that second paragraph entirely.


> --- 2.3
> 
> ISO 13250 2nd ed is actually 13250:2003, because ISO was so slow in
> publishing it.
> 
> 
Oops! Good catch

> --- 3.1
> 
> Should we mention Canonical XML here explicitly?
> 
> 
I don't want to pin myself to Canonical XML before having had chance to
evaluate it more closely. Maybe to could be referenced here though as an
input into the development process for CXTM. If it happens to be part of
the output too, so be it.

> --- 3.2.1
> 
> Maybe this is the place to say what canonicalization is, and which
> requirements this places on the algorithm? The syntax bit could then
> be 3.2.2 instead, maybe?
> 
> 
I think you are right to suggest putting the bit about what
canonicalization is in 2.1. Just the perinent part can be repeated here.
> --- 3.2.2
> 
> You lost me here. What does this mean?
> 
> 
The intention was that there should be some canonical ID for every
object in the topic map. Perhaps this is actually not needed at all as
long as there is a canonical sort order.

> --- 3.2.3.1
> 
> I don't think we really need to compare across information item types,
> if that's what you mean. 

I do mean information item types. I believe that in terms of canonical
output there does need to be such an ordering (all Topic information
items are written before any Association information items). But as you
point out, that can be accounted for by defining the canonical form of
the TopicMap information item. So this requirement should probably be
changed to that.

> Properties never mix their contents, so
> there's no need for this. If you do mean items, please say so, since I
> think this is going to be very hard to understand if we don't use
> consistent terminology.
> 
Agreed. I'll go through and make the necessary changes.

> 
> --- 3.2.3.2
> 
> I think the sort algorithm must also guarantee that for any items A1
> and B1 the ordering must always be the same as for A2 and B2 where A1
> == A2 and B1 == B2.
> 
Agreed

> 
> --- 3.2.4
> 
> Not sure I follow this. Isn't that done by comparing the resulting
> files?
> 
> 
Err yes, thats the algorithm :-)

> --- New requirements
> 
>  - the algorithm must produce the same results on all machines,
>    regardless of locale, operating system, programing language, and
>    input format
> 
>  - the algorithm must not be sensitive to changes in the URI from
>    which the input file(s) is/are loaded
> 
Yes, those are both valid requirements and should be added.

> 
> That's all I can think of right now, but no doubt I'll think of lots
> more once I'm safely offline. If you get postcards with CXTM
> requirements on them from south-east Asia you can safely assume they
> are from me.
> 
If you spend all your time in south-east Asia thinking about CXTM I
shan't forgive you :)

Cheers,

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