[
Lists Home |
Date Index |
Thread Index
]
From: Simon St.Laurent [mailto:simonstl@simonstl.com]
>>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.
Fair enough. I was hoping that looking at the one proposal or
skunkwork put forward by one of the more eminient skunks
would focus the debate away from the fear of forking and onto the
requirements for subsetting. I do like xml-sw for its completness;
it approaches and attempts to solve several of the most common
sources of permathreads. That said, I'm not a fan of subsetting
when it is likely that the supporters of the concept are all
talking about different subsets. That would best be handled
by application profiles declared in the application specification
which is the norm today. What Mike said about the tools is
interesting, although one could envision tools that are
configurable. One could think of the system libraries of
.net system.xml from that perspective. They are not author
tools, but I don't envision authors being very concerned about
XML subsets. Information owners should be but I don't know
how to explain to them that their ping-pong ball has a
.00034 probability of being squashed within three bounces
by a conforming-to-a-subset-but-the-wrong-subset mousetrap.
>> elements, attributes, text
>>
>>are core.
>Yep. I can live without attributes if necessary, though.
Definitionally, lots of people can. I have folks here who
told everyone else to NEVER use attributes because they
would not understand them. I don't consider that good
advice because one might want to use an id and one does
have to deal with those pesky hidden namespace properties.
Assuming everyone else is incompetent is usually a bad
beginning.
Still, it gets them started on using XML and that was
a major victory. My question is, would anyone really
want an XML processor that only knows how to process
elements and text? It feels like training wheels for
a toddler.
>>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.
Yeppur. That is the point. And for some applications, CSV
does a bang up job. We know the trade-offs so we can
stay off that rabbit trail in this thead.
>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.
Agreed and when contrasted to the other simplification approaches,
it stands up very well.
>"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.
Ok, but at some point, if the subsetting thing really becomes
a W3C work item, I hope people show up with numbers backing their
requirements. It sure is better than beatings if they have the
right measures for the right environments. If size matters,
it has to be a 'fit' inside 'something'. If interoperability
matters, someone better be prepared to demonstrate the operations.
>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.
Good. I am familiar with that one from SGML days: round trip lossless
or lossless by specification. Now interoperation comes down to named
operations over markup payloads. I like that better than "XML
provides interoperability" because XML does nothing of the sort:
using XML for payloads (say messages or documents, I don't
care) in transport (say the printing on the ping-pong ball) among
systems (say the mousetraps with or without cheese) and at
least we are debating measures of the systems, not the XML.
In doing that, we may discover that the interoperation problems
are not in the XML, but in the "better-built" mousetraps.
len
|
