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

[Lars Heuer]

Hi Lars,

[resourceRef vs. resourceData]
> <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.

I'd like to have "value". It's simple and consistent with the TMDM
terminology.


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

Requiring the canonicalization makes implementing XTM writers more
complex. If I look at the org.apache.xml.security.c14n package I've to
recognize that you'll need a lot of code to provide a correct XML
canonicalizer.

If the c14n process is avoidable I'd like to avoid it.
The reason 1) is IMO not very good because duplicate suppression is
not a task for XTM but may be done internally, implementation
specific. Maybe the TM processor does duplicate suppression with XML
C14N, but the creator / writer (either human or machine) of the XTM
document shouldn't be forced to do the canonicalization.

Not forcing C14N makes it also easy to spit out XTM by applications
that are not TM processors (i.e. by a PHP script or whatever).

Best regards,
Lars
-- 
http://semagia.com