[
Lists Home |
Date Index |
Thread Index
]
clbullar@ingr.com (Bullard, Claude L (Len)) writes:
>Favored is a strong term, but OK.
You do keep pushing XML-SW forward. I don't get the sense you do so
because you dislike it, though I recognize that you aren't completely
fond of it.
>What would be
>interesting would be a comparison of Common XML
>and XML-SW to determine what features two groups
>considered essential and how they differ. You say
>the essential subset is:
>
> 2.2 Elements
> 2.3 Attributes
> 2.4 Namespaces
> 2.5 Textual Content
>
>and now revise that to unbundle the namespaces so
>
> elements, attributes, text
>
>are core.
Yep. I can live without attributes if necessary, though.
>Given there are those who say attributes are a botch,
>an even more conservative position is
>
> elements, text
>
>and if we go more minimal than that, we are back to CSV.
If you go more minimal than that, you're not really doing markup any
more. That's fine, but you need to call it something else.
>I have seen message types with exactly that last set
>plus the XML declaration, so it isn't unthinkable but
>I'm not sure it's worth a dll.
For embedded systems I think it might well be, though DLL would perhaps
be the wrong style there.
>It would be interesting to hear from the supporters
>of a subset if their applications can work with only
>the features of either of those two extreme minimal
>subsets, or even the documented Common XML core. Given
>the extensions, Common XML is XML, yes? So what does
>it achieve except to document where the reliability
>begins to drop off, and that is a claim in need of
>some documentation itself.
Common XML was a "fix-in-documentation" exercise based on the experience
of people on SML-DEV. It's a different approach from a formal subset,
but I think it produces worthwhile conversation.
>No aspersions intended,
>Simon, just a desire that as this thread continues,
>we make sure we are debating verified results and not
>our intuitions unless we denote them as such.
"Verified results"? Uh, should we just abandon the conversation here,
develop timed test-suites, and forget that markup is a painfully human
process? Next you'll be asking for concrete, when I already dumped a
hideous batch of angle brackets on the list yesterday.
I'm content to work with the experience of people willing to contribute
to the conversation. If some of that experience is expressed as
intuitions or spec exegesis rather than lab results, that's fine too.
><rant>Everyone claims that they are defending "interoperability"
>yet I don't find a definition for that term so I
>have to wonder if all are defending the same thing.
>I've yet to figure out how XML succeeded because
>it provides "interoperability". It provides a common
>syntax for exchanging data via some transport (network,
>floppy, carrier pigeon with text wrapped around the
>good leg). That is where markup stops but the claims
>go on.</rant>
Common XML's working definition of interop came from a couple of
different sources, but probably the easiest ones to focus on information
preservation through a round-trip and the options for losing information
given to non-validating parsers. About the only case that's difficult
in all of that is processing instructions, which must get reported but
have few generic semantics.
Beyond that kind of interop, we let other people make the claims.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org
|
