RE: On subsetting XML...

Risky either way, but the least risk seems to 
be not to subset given that is the risk we are 
all accepting today.  I'm not sure that 
people who won't figure out either language 
that says "ignore PIs" or how to do that 
will be happy without getting their precise 
subset.  Years and years of practice proved 
people weren't happy without a subset of 
SGML (so XML), and every day we get yet 
another "What are these attribute things 
doing in this tree?" question.  So I'm not 
convinced the tide is ever really stemmed.

The processor code will fork.  That's a dllHell 
issue.  Let the buyer beware.

The SOAP folks have yet to present a compelling 
argument for the subset as an officially sanctioned 
subset.  It seems like extra work for the W3C given 
the application documentation already prescribes 
which features should be used.  I am more compelled 
by the problems of IDs and well-formed documents 
because that is a case, according to the advocates, 
one sees often and is a side effect of XML 1.0/1.1 
relying on well-formedness and for which, the only solution 
now provided (process the DTD or schema) is said 
to be wholely unacceptable (we have no numbers to 
support that but...).  So that one jumps out as a 
problem in XML itself, not in the application semantics.

len


From: Norman Walsh [mailto:Norman.Walsh@Sun.COM]

If there's an official subset that's "small enough", I think they
might reach the conclusion that "it's not an ideal subset for us, but
it's close enough, let's use that" and avoid forking endlessly.

I don't see *any* evidence that SOAP is going to fail to reach PR
because it doesn't support doctype declarations or PIs. And so the
forking *will* occur. I'd like to stem the tide before it overflows
all the barricades.

Received on Friday, 17 January 2003 10:56:25 UTC