Re: [xtm-wg] An XTM test suite

[Lars Marius Garshol <larsga@garshol.priv.no>]

* Steven R. Newcomb
| 
| I think this idea is either a very good idea, or a very
| bad one, depending on what you intend, which isn't
| entirely clear from your note:
| 
| Canonical XTM, type A (I oppose this idea):

The idea is _not_ a simplified XTM syntax designed to be simpler to
parse and implement. (It will probably be simpler than XTM, but only
because it must.)

Certainly, it is _not_ indended as a competitor to the XTM syntax,
only as a tool for making applications that support XTM 1.0 more
reliable.

| Canonical XTM, type B (I like this idea):
| 
|   Perhaps you're talking about an entirely new syntax
|   whose purpose is to serialize every aspect of the
|   application-internal result of an application's
|   processing of a <topicMap> element (including, of
|   course, the result of processing any <mergeMap>s
|   within it, and any <mergeMap>s within the merged
|   <topicMap>s, recursively).

This is close to it, yes.  The idea is that in this syntax, any two
topic maps that are logically equivalent will have the exact same
serialized representation.

A canonical XTM document must

 - be UTF-8-encoded

 - have all elements (topic, association, baseName, topicRef etc) in a
   specific order, probably based on the lexical order of IDs and
   names

 - have all attributes in a specific order (and possibly conform to
   the canonical XML specification)

 - use insignificant whitespace in a pre-determined way

 - be consistent (as per annex F)

 - have all externally referenced topic map documents merged in

 - have only normalized URIs

 - represent all topic map constructs in a single way (so, for
   example, <instanceOf> and <scope> will only ever contain
   <topicRef>, since <subjectIndicatorRef> and <resourceRef> are
   implicit <topicRef>s)

| Syntactic equivalences between XTM <topicMap> elements, as these are
| discussed in XTM today, are insufficient to define what topic map
| information actually is.

This I don't follow. You seem to imply here that something more than
what I propose above is needed. My problem is that I have a release
schedule to meet and must act very quickly indeed. So if something
radically more complex is needed I would prefer to do this first, and
then that as a second stage.

| * When XTM was formed, there was consensus that
|   rigorous correspondence between XTM syntax and the
|   topic map information that should be derived from XTM
|   documents was necessary if we are going to make our
|   contribution to global knowledge interchange.  We
|   don't have that rigorous specification yet.  I think
|   it's absolutely essential.  The syntax is only half
|   of the job.

With this I wholeheartedly agree. The sooner we have an object model,
the better.
 
| I'm interested in making Canonical XTM, Type B (as described above).
 
If that matches what I described above, then that's excellent!

--Lars M.


------------------------ Yahoo! Groups Sponsor ---------------------~-~>
eGroups is now Yahoo! Groups
Click here for more details
http://click.egroups.com/1/11231/0/_/337252/_/982311576/
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com