[sc34wg3] Almost arbitrary markup in resourceData

[Lars Marius Garshol]

* Lars Marius Garshol
|
| I think that question is irrelevant, really. If there really were a
| problem with embedding arbitrary markup in XTM the question would be
| relevant, but I don't think there is, nor does anyone on the list
| seem to think there is, except for you. And you can't even come up
| with examples of potential problems or arguments for why simply
| storing the markup is harmful.

* Murray Altheim
| 
| I think the problems in the RDF world are well known, as are they in
| XML with XML Namespaces generally. I'm not going to enumerate those
| here.

I don't think you have to, either, since we agree that those are
problems. What I am asking you to do is to give examples or in some
other way substantiate that those problems will apply to XTM 1.1 if
XTM 1.1 allows arbitrary markup in <resourceData>. I don't think they
apply in that case, but you clearly do. Why? That's what I'm asking
you.

(The two issues you list below are answers to that question, but see
my replies.)

| As for potential problems, how about the fact that you could no
| longer validate XTM? 

That's no problem. The RELAX-NG schema in the next XTM 1.1 draft will
allow such validation. It won't validate the non-XTM markup, of
course, but users can deal with that themselves, or ignore it.  Either
way it won't hurt those who don't use XML inside XTM.

| Or more generally, the fact that we're a small and fragile market
| right now and that arguments for supposedly necessary features that
| could enlarge our market might just as easily be met by arguments
| against the destabilization you'll create by splintering that market
| we currently have into XTM 1.0 and XTM 1.+.

I agree this is something that must be considered. We've already
changed XTM by adding <instanceOf> inside <baseName>, but admittedly
this is a more invasive change.

I've long been of the opinion that we shouldn't change XTM 1.0 at all
if we could avoid it, but in the case of <baseName> we found no other
solution to the TNC problem, and so we made the change.

Having made that change we've already done the splintering. Admittedly
this change makes it bigger, and personally I would prefer not to make
this change. What's changed my mind is that there is an obvious need
for this, since so many people are doing this in different ways
already.

It's a trade-off, but there seems to be a majority for trading off in
this particular direction.

| The size of this group isn't large enough and the fact that we all
| bring our own agendas means that neither you nor I are able to speak
| for the needs of a general population, [...]

Of course not. That's why I brought it up in the ISO meeting, and the
meeting ruled that we should do it. We've now discussed it one more
time, and again there is a majority for making the change. 

What will happen now is that the change will go into the official ISO
Committee Drafts, and that gives the wider user community a chance to
voice its opinion on this in the ballot period. What more we can do to
find out where people stand on this issue I don't really know, but
what's clear is that I'm not going to drop this just because a single
person objects.
 
* Lars Marius Garshol
|
| As I've already explained to you: your proposed solution achieves
| nothing, since it implies stripping the markup back out of the XTM
| document before XTM processors can see it.
 
* Murray Altheim
|
| You've not implied correctly. The idea of having *one* hybrid markup
| language would mean XTM processors do see it, but only see one kind
| of markup, not arbitrary markup, and handled like any other XML. No
| strange "storage", serialization and de-serialization of markup.

OK, but why do need the XHTML-stripping XSLT stylesheet, then?

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