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

[Robert Barta]

On Mon, Mar 24, 2003 at 11:48:34PM +0100, Lars Marius Garshol wrote:
> * Robert Barta
> General Comments:
>
> |   - 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.
> 
> I'm afraid you'll have to explain a bit more here, Robert. What is the
> problem, and how would you prefer to solve it? I suppose you are
> referring to the source locators?

Yes, this is more a general rant and can be easily ignored. I was simply
wondering that the IDs - actually an XMLish way to address a particular
part of an XML __DOCUMENT__ is "used" (read abused) to address now a topic
or particular parts of topics.

And, if we already have this, why does it only work for particular things
and not for others?

Again, can be ignored since this cannot be changed easily without affected
probably a lot of other stuff.

> |   - Issue(xtm-where-resourceref)
> | 
> |     It would REALLY be good if the clumsy and cumbersome
> |     distinctions between resourceRef, topicRef, .... would
> |     disappear. They slow down parsing.
> 
> Not sure I follow here. You mean you would prefer if only topicRef
> were used to refer to topics? I made that comment myself just before
> XTM was published, but it was too late then, and it's definitely too
> late now. :)

:-) Maybe it is just my programmer's soul, but here I would have
designed my TM data structures to be all about topics, regardless
where they come from:

 - In case of topicRef this would simply be a pointer to the topic
 which is already declared in the map.

 - In case of resourceRef a topic representing this resource would be
 created (just as the SAM says),

 - similar for subject....

This distinction would not appear then in XTM (or any other
serialisation).

Please correct me if this would not work. Maybe it is not completely
practical but I would have preferred a rather orthogonal format. Now
SAM has to compensate for this. Which is ok, per-se.

> |     Why not allow topics everywhere, regardless where they come from?
> 
> Or did I misunderstand? Here you seem to say that resourceRef should
> be allowed everywhere?

Since we always use a reference to a topic, there would only be a
topicRef.

> |     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.
> 
> True, but the SAM provides mechanisms for expressing this even if the
> source is not an XTM document.

Yes, weird ;-))

> |   - Issue(xtm-normative-schema)
> | 
> |     I would take section 2 as authoritative and the rest
> |     informational.
> 
> Appendix B, or section 2? The issue is talking about whether the DTD,
> the RELAX-NG schema, or the XSDL schema should be normative. Section 2
> is the syntactical part, while section 3 tells you what it means.

This issue has disappeared (which is a good sign, I guess :-)

> | ad 2)
> | 
> |   - first para: can be found in _Appendix_ B....

There were no further remarks/questions/objections to this in this email...

\rho

> | 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.
> |