[sc34wg3] Almost arbitrary markup in resourceData
Murray Altheim
sc34wg3@isotopicmaps.org
Tue, 11 Nov 2003 11:29:14 +0000
Lars Marius Garshol wrote:
[...]
> What the standard will say very clearly is that XTM processors are
> expected to take this additional markup and store it, without making
> any attempt to interpret it in any way. It just goes into the data
> model instance that is built, and is stored there. The only difference
> between
>
> <resourceData>XTM is <em>really</em> cool.</resourceData>
>
> and
>
> <resourceData><![CDATA[XTM is <em>really</em> cool.]]></resourceData>
>
> will be that in the first case the processor will *know* that it's
> dealing with XTM, and thus can support transformations of it at
> publishing time, queries on it, and so on.
>
> That's it, really. It's meant to be a more convenient way to work with
> XML content in topic maps, by not forcing people to put one-line XML
> markup snippets into external files.
Well, if it's *any* arbitrary XML markup, it's still the same problem.
And while this may sound obstinant, I'm not modifying my tools to
handle arbitrary markup.
> | In my opinion, it's clear not okay, and not cool. The first time
> | somebody opens up that topic map and sees *nothing* it's not
> | cool. And which version(s) of XHTML are you going to allow? There's
> | about five right now. There will be more, many more. Or can people
> | put *anything* there?
>
> The answer is indeed *anything*, but none of it will have any topic
> map semantics.
>
> | I don't buy for a minute the typical W3C argument that you can just
> | ignore markup you don't understand.
>
> XTM processors are not supposed to ignore this; they are supposed to
> store it without modifying or interpreting it.
That is the strangest idea I've heard in a long time. What does
"store" mean? How does this end up being used? Does "<em>really</em>"
get stored, leaving "XTM is cool?", or does the proposal mean just
pulling out the tags so that the original PCDATA is intact? A good
example of a problem here would be if "really" was "not", where
"storing" would mean a decided change of meaning.
> | That's a proprietary hole in XTM, where vendors will be able to
> | "legally" put proprietary markup that other users will have to play
> | catch-up to correctly process.
>
> It was the users that pushed for this, not the vendors.
It doesn't matter who pushed for it. It's still a proprietary hole.
> | I think the whole thing smells. That's been my opinion of mixed
> | namespace markup since about 1998, so I suppose there's no surprise.
>
> Well, I agree with you, but we're not allow mixed namespace markup in
> the usual sense. We're allowing XML content in base names, variant
> names, and occurrences. That's *not* the same thing.
Wha? I never even knew about this one. Sounds like I'll just be
sticking with XTM 1.0. Are you guys sure you're not mucking up
the works? What are the requirements on the new version? Is
interchange one of them?
> | But this in the full knowledge that suddenly there's more than one
> | XML interchange markup language for topic maps, which simply can't
> | be a good thing for our community, our vendors, our potential
> | customers.
>
> We *really* don't want that, but it's not what we are creating,
> either.
I don't follow. If you allow arbitrary markup, you're not even
creating a markup language, you're creating a soup in which
anything goes, and in which meaning is just as arbitrary as the
markup (pretty much by definition).
Murray
...........................................................................
Murray Altheim http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK .
Allegations of animal mistreatment against Yukos surfaced in an
inspection of a farm belonging to a Yukos-affiliated company in
the Siberian region of Yakutia, news reports said. Male and female
rabbits were kept together and "couplings take place unsystematically,"
the Interfax news agency said.
http://www.sfgate.com/cgi-bin/article.cgi?file=/news/archive/2003/11/06/international1705EST0747.DTL