- From: Paul Grosso <pgrosso@arbortext.com>
- Date: Wed, 04 Dec 2002 15:57:05 -0600
- To: www-tag@w3.org
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