logo       

Re: XTM Datatypes [Was: Adding weigths to associations]: msg#00081

text.xml.xtm.general

Subject: Re: XTM Datatypes [Was: Adding weigths to associations]


(Sorry about the delay on this. I'm not able to keep up with my mail
at the moment.)

* Martin Bryan
|
| Other than the need to identify which constructs your custom
| syntaxes match to in 13250 there is no need for support from the XTM
| syntax, but you do need to flag at least the root element as being a
| topic map, just as the HyTM syntax needs you to identify which of
| the AFs an element matches.

Why do you need to flag the document element as being a topicMap
element? Surely it's enough to be able to detect one such element
within the document?

(I take it this means that you are abandoning the requirement that XTM
support the definition of custom syntaxes.)

| Note that I stated " XTM also requires the creation of extra
| "topics" to be created to cover the roles used in 13250." Your
| response does not mention role types, but I presume you would
| include these in your list as part of the etc.

I would.

| If I want to retain information about the type of each role so that
| I can select views of the topic map based on roles I presume you
| must expect them to be re-constructed as topics within XTM.

Yes. Is that a problem?

| [Martin explains why markup is not limited to inline occurrences in
| HyTM]
|
| 13250 uses TMBrid to indicate those points at which you are allowed
| to bridge out to non-HyTime forms. This occurs in dispname (which
| can be non-textual, or could contain text with markup that affects
| the display, such as bold and italics) and addthms (to allow
| comments to be used to explain why the themes have been added), as
| well as part of the model for the root element of a topic map (so
| that you can put in data that the topic map can reference).

I understand. I don't know HyTime very well, so I wasn't aware of
that. If we allowed markup in <resourceData> the difference between
XTM and HyTM would only be that XTM does not allow arbitrary markup
within <mergeMap>. Personally, I think disallowing that makes good
sense. Once you've deserialized the XML document there is really
nowhere to put that information in any case.

(I've added the issue of whether arbitrary markup should be allowed
within <resourceData> as an issue in the XTM syntax spec, with the ID
xtm-resourcedata-markup.)

--
Lars Marius Garshol, Ontopian <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC <URL: http://www.garshol.priv.no >


<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise