[
Lists Home |
Date Index |
Thread Index
]
From: Gavin Thomas Nicol [mailto:gtn@rbii.com]
>I personally don't see the real need for a subset from an application-building
>perspective, but given the amount of consternation other people have, I would
>say there is probably some value in a syntax subset.
>Assuming there is to be a subset, it should be just that, a subset. Remove
>anything that is not directly a syntax issue. That'd bring us right down to
>UnicodeAndAngleBrackets.
As John Cowan describes it, the XML Namespace is purely syntax. Yet, why
would a colon be special and xml: be reserved unless they were semantically meaningful
to a processor somewhere sometime? The explanation that these are "just
syntax" is a nice lawyerly dodge; normatively true but informally misleading.
You don't have to answer that, but I think it useful that the pure syntax vs
data model vs application processor distinctions are already munged and there
is no going back. So we are hopefully trying to work out:
1. Is a subset a way forward?
2. Where is forward leading to?
3. What does a good candidate subset
look like? XML-SW was put forward and
some think it elegant. Why not start there?
>You'll have to excuse me here, because you're leaping from syntax and infosets
>to software components. That leap is a source of confusion IMHO.
Fair statement, but I don't think interop comes from syntax, just
data portability and yes, I don't discount the value of a shared
syntax. Interop means "something is operating" and that might
just be a parser, but it is something. Because the TAG includes "XML
helps interoperability" in the draft architecture document, it is useful
to know precisely what that means or it is just dog and pony language
and the architecture document contains language that it shouldn't.
>> To me, it keeps coming back to what services can a
>> programmer reasonably expect of an XML processor.
>What is "an XML processor"?
Bingo!
len
|
