[sc34wg3] Almost arbitrary markup in resourceData

[Lars Marius Garshol]

* Murray Altheim
| 
| Point is, arbitrary markup is a killer for interchange, whether you
| demand that processors "store" or process it. 

I don't see how it can damage interchange when processors are
explicitly required not to process it, but only to store it. How do
you see that happening?

| And storing it means that you're permitting applications to process
| it, and applications will then begin the *wonderful* competition to
| see who can out-customize an interchange syntax. All that's happened
| is that you've moved the customization up a level, from the
| processor to the application.

Murray, there's no real difference between having this stuff inline
and having it in external resources. The only difference is that we're
making life easier for the users by not requiring them to a) create
lots and lots of tiny external resources and b) resolve and then parse
the content of XML resource.

And what proprietary extensions are you worried about anyway? How are
people going to start extending XTM in proprietary ways with this?
Give us one example.
 
| Rather than doing something so odd as that, have you considered what
| the actual use cases are? 

Jim made a good list. Other things would be: representing complex data
like addresses, dividing descriptions/definitions up into multiple
paragraphs, and so on.

| If 90% of them are to just have XHTML markup, I have made an offer
| to Jim to create an XHTML+XTM DTD, which would allow people to
| inline formatting, links, etc. and we could talk somebody into
| writing an XSLT stylesheet to strip that for transformation to XTM
| 1.0, i.e., clean XTM. 

If you did that we'd be back where we started: we'd have made it very
awkward for people to have XML content in XTM. You would still have to
bend over backwards to emphasize a word in your description or break
it into multiple paragraphs.

| If ISO wanted to standardize XHTML+XTM, fine, but this wouldn't
| corrupt the use of XTM itself as an interchange, and there'd be only
| *two* targets for support, rather than the complete impossibility of
| correctly supporting markup soup.

The point is, Murray: this *isn't* like the ordinary markup soup
scenario (which I fully agree is a nightmare). We are *not* allowing
XTM to be mixed with other namespaces. We are allowing other XML to
appear inside three elements where we do not allow XTM elements, and
we require the XML to simply be stored, and not processed in any way.
So there is no mixing, and there is no soup. 

The reason I favour this is quite simply that I see this coming up
again and again and again. If we don't allow it now we'll be forced to
allow it later. Some users are already doing this, while others use
ugly hacks like

  <resourceData>XTM is [em]really[/em] cool.</resourceData>

and

  <resourceData><![CDATA[XTM is <em>really</em> cool.]]></resourceData>

and so on and so forth.

It seems to me better to extend the standard to allow people to do
what they already do, than to outlaw it when we know that although it
is hard and painful to support this it actually is a quite reasonable
requirement. 

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