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

24 Mar 2003 23:48:34 +0100

Good point. Will put that in.

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

Thanks. Good to get some feedback on this.

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

That is an idea, admittedly. The split was very much done consciously,
but nobody has ever commented on it before. Other opinions on this?

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

True. Will fix.

(The intention was that they will not be merged. Unless the
application specifically requests it, of course.) 

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

Will do.

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

Corrected.

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

Noted. This appears to be the consensus.

|   - Issue(xtm-href-whitespace)
| 
|     No, raise error. This is XML, anyway, so strictness is ok.

Noted. I also note that XML Schema does not require an error in this
situation, whereas XLink seems to. Consensus appears to lean towards
disallowing it.

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

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

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

Well, the issue is whether the ID attributes should be in the syntax
or not. Whether we should have source locators or not is a completely
separate issue.

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

|   - Issue(xtm-version):
| 
|     1.1 ? But if so, then there we need a backward compatibility
|     chapter (and maybe an XSLT sheet).

1.1 appears to be the consensus. We definitely do need to add an
appendix listing the syntax changes. An XSLT stylesheet is not needed,
since so far all previously valid documents remain valid in the new
version. (Except in lots of cases where it was anybody's guess what
was valid and what was not.)

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

|   - Issue(xtm-schema-uri)
| 
|     I like URIs a lot. Yes.

Noted.

|   - Issue(xtm-xlink-type)
| 
|     No magic here please.

This issue was a mistake, as Murray Altheim kindly pointed out.

|   - Issue(xtm-xlink-actuate)
| 
|     No magic here please. This is NOT about hyperlinks, btw.

Noted.

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

Noted.

| 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 -----
| _______________________________________________
| sc34wg3 mailing list
| sc34wg3@isotopicmaps.org
| http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
| 
| 

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >