[sc34wg3] implementer's comments on XTM, 23.2.2003, Rev1.15

[Robert Barta]

Lars et al,

Thanks for your efforts!

General comments:

  - maybe put somewhere that XTM is meant as "exchange syntax" not so
    much for authoring? As a consequence XTM strives (not yet there) for
    orthogonality.

  - I appreciate that the former XTM standard is broken apart into
    smaller, more manageable things. Much better to read.

  - I wonder whether it would be a good idea to merge the syntactic
    portions with the semantic (=SAM) ones. So for instance merge (!)
    2.1 with 3.2, 2.2 with 3.3, etc.

  - I do not like much IDs appearing someplace and not the other. An XML id
    is something VERY(!!!) internal and something very XMLish. The
    kludge of addressing topics with #topic-id is what it is, a
    kludge. It does not point to a topic but to a textual
    representation of a topic within a document. There could be millions of
    this.

ad 1)

  - paragraph 2: When consuming several maps from an XML document it
    remains unclear whether the maps should be merged or remain
    separate.

  - 'architectural processing': either explain it or make a reference

  - ....or XSLT transformation_s_ ....

  - Issue(xtm-href-xpointer):

    I would prefer if TM processing does NOT do too much link magic.
    If we keep it orthogonal then the standard has some freedom later.

  - Issue(xtm-href-whitespace)

    No, raise error. This is XML, anyway, so strictness is ok.

  - Issue(xtm-where-resourceref)

    It would REALLY be good if the clumsy and cumbersome distinctions
    between resourceRef, topicRef, .... would disappear. They slow
    down parsing.

    Why not allow topics everywhere, regardless where they come from?

  - Issue(xtm-unused-ids)

    My opinion here is that ALL ids should disappear, even the topic
    ids. Implementations may keep them or may reissue new ids for an
    application. These can then be used for reification purposes.

    A reification of a baseName via a link into an XML document is
    weird anyway. It only works for XML while the majority of topics
    will come from other sources.

  - Issue(xtm-version):

    1.1 ? But if so, then there we need a backward compatibility chapter
    (and maybe an XSLT sheet).

  - Issue(xtm-normative-schema)

    I would take section 2 as authoritative and the rest informational.

  - Issue(xtm-schema-uri)

    I like URIs a lot. Yes.

  - Issue(xtm-xlink-type)

    No magic here please.

  - Issue(xtm-xlink-actuate)

    No magic here please. This is NOT about hyperlinks, btw.

  - Issue(xtm-xmlbase-everywhere)

    No. xml:base is an ugly cludge which is mostly used to hide design
    flaws. If someone needs it he can create submaps. I could live
    with it on the toplevel, but that's about it. :-)

ad 2)

  - first para: can be found in _Appendix_ B....

ad 2.1)

  - ...the following _meaning_

  - Issue(xtm-fixed-attributes)

    I do not quite understand why the default namespace HAS to be set.
    It seem perfectly feasible to me to use different prefixes and use
    another default name space, especially since the <topicMap> code
    can now appear (yippie!) inside any XML document.

    What is the problem with

    <rumsti:topicMap xmlns:rumsti=".....xtm/1.0">

    This would allow to read a map without consuming a DTD, right?

ad 2.2)

  - Comment: it is possible to create topics without names.

  - Why is the ID for the topic REQUIRED? What for?

    If I generate topics from a database, I will have to invent
    IDs out of the blue just to be XTM conformant?

ad 2.3)

  - typo: elements

  - Issue(xtm-subjectidentity-children)

    Allowing different URIs here, would this not contradict the idea
    that it IS an identity. If there are two URIs involved then the
    application should use URNs for it and map them separately.

    Probably, I do not fully understand the problem here.

ad 2.7)

  - Issue(xtm-variantname-deprecate):

    Yes, YES, YES!

ad 2.8)

  - Issue(xtm-parameters-deprecate):

    Yes, YES, YES!

ad 2.9)

  - I wonder whether this should be allowed:

    <scope/>

    indicating the 'unconstrained scope'.

    Since we are there, for an application it would be MUCH simpler to
    only allow ONE topic for a scope. If someone wants to have two
    topics for a scope, he can build one for this purpose.

ad 2.12)

  - Issue(xtm-resourcedata-markup)

    No special markup handling. Best would be completely transparent
    handling.  One issue here is MIME typing, but I guess

     <resourceData rhospace:MIME="application/weird">(*&(**&(&&*^&*^</resourceData>

    should work.

ad 2.14)

  - can we enforce here, that there is ALWAYS a playing topic and if
    there is none, then the predefined topic "something" is
    used. This is an exchange syntax, so it should be simple.

    Same for the roleSpec.

  - Issue(xtm-member-id)

    No ID, please. There must be other means to reify things
    consistently in a map.

ad 2.15)

  - allow resourceRef as well? Why not consistently, even though it
    may not make perfect sense everywhere?

ad 2.16)

  - Issue(xtm-topicref-notopic)

    I would not see it as an error, although the TM processor might
    flag a warning. Autogeneration of topics works pretty well.

  - Issue(xtm-topicref-notatopic)

    Yes, it would be an error, but I do not think that inside an XTM
    document one can enforce that a URI is really pointing to a topic.
    What about

      tm:/my.topicmap.server/mapA/mapB/topicT

    This can only be checked at processing time.

ad 2.18)

  - typo: significance

ad 2.19)

  - why having 'FIXED' here?

  - Issue(xtm-mergemap-reference)

    Since we do not have a special class of URIs which point to Topic
    Maps specifically, we have to stay on the document level. And if
    we have allowed a document to contain several maps, so be it.

ad 3)

  - the first bullet is not all too clear to me.

  - subsection "Processing" cannot be found.

  - "document order" is arbitrarily restrictive.

  - Issue(xtm-namespace-support):

    Yes, namespace should be ok.

  - Issue(xtm-unknown-elements)

    Forward compliance would be more important for me.

ad 3.14)

  - ...If the member element _contains_ no roleSpec....

ad 3.15, 16, 17)

  - should the processor flag a warning if it creates a topic item
    out of the blue?

ad 3.18)

  - if the .... URI has already been processed, nothing further is done...

    What if the map is stateful, i.e. depends on the time when I load it?
    What about a map which contains a topic MSFT-stock-quote and the value
    differs.

  - If external reference cannot be followed => raise exception

  - If reference is not external, leave it up to the application

  - Issue(xtm-mergeMap-and-topicRef):

    If the processor pulls in a map because of a topicRef (I can see
    nice DoS attacks against TM servers coming), then I would treat
    this completely separate from a mergeMap.

  - Why is a merged-in map not completely inhaled by the sourrounding
    map? What is this business with a subordinate map. This is a completely
    new concept and would have to be dealt with from the beginning on.

ad 4)

  - Comment: There is a version number here. See above.

  - bullet 2: "XTM constraints" cannot be found anywhere.

  - bullet 4: this is a tautology.

    It is clear what is meant, but it is too weak for a standard.



----- End forwarded message -----