[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: The subsetting has begun

• To: "'Simon St.Laurent'" <simonstl@s...>, XML Dev <xml-dev@l...>
• Subject: RE: The subsetting has begun
• From: "Bullard, Claude L (Len)" <clbullar@i...>
• Date: Wed, 26 Feb 2003 14:15:31 -0600

From: Simon St.Laurent [mailto:simonstl@s...]

>>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

• Prev by Date: Re: The subsetting has begun
• Next by Date: XML for the Restaurant Industry
• Previous by thread: Re: The subsetting has begun
• Next by thread: RE: The subsetting has begun
• Index(es):
  • Date
  • Thread