OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: Dangers of Subsetting? (was RE: Pull-based XML parsers?)

[ Lists Home | Date Index | Thread Index ]
  • From: Michael Brennan <Michael_Brennan@Allegis.com>
  • To: "'Mike.Champion@SoftwareAG-USA.com'" <Mike.Champion@SoftwareAG-USA.com>
  • Date: Fri, 10 Nov 2000 17:18:34 -0800

Title: RE: Dangers of Subsetting? (was RE: Pull-based XML parsers?)
There are a lot of people with many different opinions about what features are useful in XML and what are not. These opinions are all valid, but anyone who values interoperability must be willing to make compromises in this regard. If "profiling" means that every time I obtain an XML parser, I need to peruse through a shopping list of features to see which ones this parser supports, than the value of the standard has been greatly undermined. What is the motivation of wanting such profiling? Is it to make it easier to implement parsers? Think about how many times developers obtain and use a parser versus how many times developers implement a parser. Does it really make sense to greatly complicate matters for those trying to obtain and use a parser in order to simplify matters for that much smaller number of developers who are going to implement parsers?
I have very high regard for Common XML and the work that went into defining it. I would be happy to see an official recommendation specifying Common XML. I think there is value in having layered standards and protocols where there is a clearly identifiable, simple core, and additional layers that build on top to provide richer functionality without forcing those who don't need that functionality to deal with the added complexity. For that to work and be of value, though, the number of layers needs to be kept small and manageable. In addition, I think this works best if the "upper" layers are complete supersets of the lower layers, rather than being arbitrary subsets with (possibly) additional functionality. If instead of having layers, you have a shoppping list of features and implementors can provide profiles specifying the particular features they are supporting, then you have made things far more complex for those trying to leverage the technologies and you have undermined the value of the standard.
The only situation where "profiling" of this sort makes sense, in my opinion, is in cases where a one-size-fits-all general solution cannot adequately address requirements. In such cases, leveraging profiling for architectural flexibility can be a good solution. If, however, the motivation is to simplify matters in the small number of cases where someone is implementing a general tool at the expense of greatly complicating matters in the much larger number of cases where someone is going to use a general tool, then I think the priorities are all wrong.
I admit I have no understanding of ISO 8859 Annex K, and I'm no expert on standards. But I do know quite a bit about the pains I have gone through as a developer. In my own work, I have always been willing to put extra effort into a tool I build if it is going to simplify things for me in the many instances in which I use the tool. In my opinion, standards should be written with the same philosophy in mind.
-----Original Message-----
From: Mike.Champion@SoftwareAG-USA.com [mailto:Mike.Champion@SoftwareAG-USA.com]
Sent: Friday, November 10, 2000 12:55 PM
To: xml-dev@lists.xml.org
Subject: RE: Dangers of Subsetting? (was RE: Pull-based XML parsers?)

    -----Original Message-----
    From:   Rick JELLIFFE [SMTP:ricko@geotempo.com]
    Sent:   Friday, November 10, 2000 3:40 PM
    To:     xml-dev@lists.xml.org
    Subject:        Re: Dangers of Subsetting? (was RE: Pull-based XML parsers?)

      No-one has said Common XML (as a data format) is dangerous.
      I said that developers should boycott parsers that call themselves
      XML but only implement a subset except for specific-purpose systems:
      so you it is fine to make a subset parser (e.g. for SOAP) and
      say "this is a parser for a subset of XML" but it is not fine to
      say "this is an XML parser".

    This makes perfect sense to me.  I'm sorry if I misunderstood the original "boycott" post (I guess I thought it was clear that kXML just claimed to implement "Common XML", but let's not reopen old wounds).

     And thanks for the explanation of ISO 8859 Annex K -- I guess if anyone gets really serious about promoting  "Common XML Core" or "MinML", it would make sense to define it in the official Annex K manner first.

    One issue that generated a lot of traffic on this list a year ago was whether XML needed a similar mechanism with which one could define a "profile" (as Len Bullard used the term it in http://lists.xml.org/archives/xml-dev/200011/msg00176.html) that constrained the types of markup to be used in a class of  XML applications (e.g., "no PIs, notations, parsed entities or CDATA sections, please" - perhaps if the format needs to be "Desperate Perl Hacker Friendly"). Isn't this more or less what Annex K allows? Would the people who so vigorously oppose defining "subsets of XML" in the name of interoperability be averse to adding a mechanism like this in a future version of XML? 


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS