Lists Home |
Date Index |
> -----Original Message-----
> From: Bullard, Claude L (Len) [mailto:email@example.com]
> Sent: Friday, February 28, 2003 10:44 AM
> To: Cavnar-Johnson, John; 'XML Dev'
> Subject: RE: [xml-dev] The subsetting has begun
> Thanks for that summary. I noted also from the TAG
> list the action for Liam to begin to look at the
> issue. What I haven't seen is a decision to
> create a new class of parser and much of the
> subset discussions come down to that when
> the costs are assessed, and it will ripple
> into every area of XML application or support.
True, I'm just suggesting there should be such a decision. I look at the
potential value and cost and think that it is worth doing.
> At least this is one that can be done at
> leisure and not in haste as XML itself was
> done. That is why a review of XML-SW, Common
> XML, the SOAP requirements and so forth are a
> good exercise.
I strongly agree. I haven't seen much discussion of those things on
this list, unfortunately. Folks seem more inclined to rehash old
battles, wander off into esoteric debates, and excoriate the convenient
> It will raise hell in the documentation world
> where DTDs and entities remain an article of much effort
> and considerable benefit. Again and as loudly
> as I can say it, a fracture between the documentation
> and message worlds of XML will have serious
> consequences for XML. Caveat vendor.
I disagree here. I don't see a fracture between users of validating
parsers and non-validating parsers today. What's the basis for your
assertion that this will have serious consequences? Nobody's saying
that the documentation world can't keep there current tools and
methodologies. I think the theoretical users of the new parsers have
little or no interaction with that world anyway. I hate to see this
false dichotomy between doc heads and data heads perpetuated. I'm
interested in systems that integrate business documents (purchase
orders, contracts, etc.) with relational systems. I consider myself
very "document-oriented", but DTDs, entities and such don't buy me much
of anything and the non-optional nature of the internal subset is
> Yes, the consensus among those
> who desire a subset is to take out DTDs, DOCTYPEs,
> and entities. What cannot be decided at this
> time is not simply which specifications cannot
> be supported by an implementation that relies on
> these features, but how to proceed in the case
> that an implementation that requires the features
> being removed would proceed given a new implementation
> or specification built over the subset. Duplication
> leads to more revisions in the code base. That
> has costs.
How is this different from the current division between validating and
> From: Cavnar-Johnson, John [mailto:JCavnar-Johnson@sark.com]
> I think there is a great deal more consensus than the discussion on
> list would lead you to believe.