[sc34wg3] XTM 2.0: resourceRef vs. resourceData, embedded XML

Lars Marius Garshol larsga at ontopia.net
Tue Mar 21 15:51:08 EST 2006


* Lars Heuer
>
> - resourceRef vs. resourceData
>   Is this distinction necessary? Why is the datatype xsd:anyURI  
> handled
>   seperately from every other datatype?

There are two reasons for this:

   1) Historical baggage. Conceptually, external occurrences have been
      given considerable prominence in Topic Maps. Giving them an extra
      element emphasizes this.

   2) Convenience. External occurrences occur very frequently in XTM,
      and this saves having to put in the datatype URI.

Having said that, neither argument is terribly strong, admittedly.

>   Possibilities:
>   a) Remove the resourceRef element and use the resourceData for
>      xsd:anyURI and all other datatypes
>   b) Remove resourceRef and resourceData and introduce an element
>      "typedValue"
>        typedValue = element typedValue { datatype?, any-markup }
>      or just
>        value = element value { datatype?, any-markup }
>
>      that is used for all occurrence and variant values.

Both of these are possible. Personally, I don't like the <typedValue>  
name, but I agree that if we do merge the elements <resourceData> is  
not exactly the perfect choice, either.

<value> has a lot of merit, but is already used for topic names where  
the only datatype supported is xsd:string. We could have different  
rules for this element depending on context (RELAX-NG supports that),  
or we could use different element names.

Opinions on this would be welcome.

> - Embedded XML
>   I wonder if the canonicalization of XML is really necessary.
>   Isn't it just enough to put the XML into an <![CDATA[  ]]> section?

There are two reasons for the canonicalization:

  1) Duplicate suppression.

  2) Simply keeping the XML as text doesn't work, as you need to  
preserve
     the namespace declarations in context at that point.  
Canonicalization
     does this.

In theory, we could ditch canonicalization and simply do 2) instead.  
This has never really been discussed in any great depth, so input on  
this would be welcome.

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




More information about the sc34wg3 mailing list