XML-* [was: ... XML subsetting...]

At 13:05 2002 12 04 -0800, Tim Bray wrote:
>Paul Grosso wrote:
>>I am not yet convinced that there is widespread
>>agreement that it makes sense to subset XML).
>
>I have also long been opposed to subsetting XML; those with a long memory may recall some fairly passionate debate on this subject in the early days of the old XML Syntax WG.  However, I think experience has taught us lots of things, of which two stick out in my mind:
>
>1. Entities are way more trouble than they're worth in lots of applications, and
>2. It's a mistake for XML to jump into bed with *any* schema language.
>
>For these reasons I think subsetting out the DTD is long past due.  I think that "basic XML-in-practice" de facto includes namespaces, xml:base, and the infoset.  Thus XML-SW.  Note that all XML-SW docs are conforming XML 1.*, and that transforming XML 1.* processors to XML-SW processors would in every case involve substantial reduction and simplification, and no new code.
>
>So I think there's a quick kill to be had here with significant benefit to the community (among other things, removing DTDs allows for a radical re-org of the XML spec with vastly increased readability).
>
>*If* we could think of a way to deal with the process issues I think there is low-hanging fruit here for the Core WG to grasp.  Obviously what everyone worries about is 138 people piling into the Working Group, each with just one little feature they want added.  A carefully-chosen set of ground rules could maybe work around this, but creativity and dedication would be required.  -Tim

I am not sure what I think (though I'm generally skeptical
about the need to do anything here).  But let me raise
some of the arguments already raised the last time the
XML Core WG discussed this.  (I'm not sure I agree
100% with everything I say below, but I do believe they
include some good points.)

1.  Arguments about making XML easier to implement are
not effective.  We went through that exercise when XML 1.0
was developed.  XML is already implemented in so many places, 
that arguments about implementation ease are hard to take 
seriously.  Besides, the ultimate beneficiaries of specs 
are the users, not the implementors.  The only point about 
making something easy to implement is so that it gets
implemented widely, and it's hard to argue that XML isn't
already widely implemented.

2.  As far as user requirements, it is hard to see how removing
capabilities from XML can benefit users.  Users use what they
use, and they might be negatively impacted if you remove some
feature, but how can they be positively impacted by removal
of features?

3.  As far as adding features, the (only somewhat facetious)
    argument goes like this:
  a.  Any attempt to develop an XML 2.0 will realistically
      take at least two years from start to Rec, and that
      only if you select only the most crucially needed
      features to add (and that doesn't include getting
      wide and interoperable implementor support).
  b.  Any feature that can wait two+ years can't be needed so 
      badly as to be crucial enough to consider it as a possible
      addition to XML 2.0.

The last time the WG discussed this, we were very far from
consensus on what to do or even if we should do anything.  
Therefore, before spending major time and effort to develop XML 2.0,
it would be important to get a firm statement from the AC that
we should invest this effort and what the desired scope/direction
should be.

paul

Received on Wednesday, 4 December 2002 17:00:21 UTC