Re: [xml-dev] Debating "civil disobedience" against overlycomplicatedspecs

[Eric van der Vlist <vdv@dyomedea.com>]

Evan Lenz wrote:

> Eric van der Vlist wrote:
> 
>>Even this definition is blur and cannot fully answer the question asked
>>by SOAP: is the doctype markup syntax or document content?
>>
>>I would say it is markup syntax, but this perception light be
>>application dependant...
>>
> 
> DOCTYPE declarations are not in this gray area by any precedent that I've
> seen.
> 
> As you pointed out in the previously cited email, the XML Recommendation
> very carefully spells out the rules for validating and non-validating
> parsers. There is no option for usurping those rules and disallowing DOCTYPE
> declarations.


That's been my first reaction and there is no question about the 
behavior of both validating and non-validating parsers.

Now, if we take a step backward, when an application gives a business 
rule that cannot be enforced by a DTD, it gives an additional test which 
the application must perform after the parser has given them the content 
of the document (as SAX events or a DOM tree or whatever).

The doctype information is available in the content given to the 
application by some of these parsers (at least for DOM since level 1) 
and, without changing the way these parsers behave in conformance with 
the req, the constraint "no doctype" may be tested by the application 
like any business rule.


> 
> I know of no other vocabulary that calls itself an application of XML in
> which I do not have the freedom, if I so choose, to declare an internal DTD
> subset in order to declare an internal entity. According to the XML spec,
> this practice is 100% interoperable among all XML processors, because they
> are *all* required to process the internal subset and resolve internal
> entities declared therein. An application without this guarantee should not
> be called an XML application. Instead, it is an application built on
> something other than an "XML processor".


A parser without this guarantee should not be called a XML parser :=) ...

I am not saying that I think it should be done, but the more I think 
about, the more I think that it's not that simple.

The answer can probably not be found in the current releases of the recs 
and, you're right, it's mainly a question of interoperability and 
practices, i.e. something more subjective than I had first thought.

Eric


> Sure, there are interoperability issues--they are part-and-parcel of the
> shades-of-conformance mess we get with XML 1.0. sml-dev and perhaps the XML
> Core WG can deal with these issues. However, they are not well addressed by
> putting the name "XML" on something that simply dismisses large parts of the
> XML Recommendation.
> 
> Evan Lenz
> XYZFind Corp.
> 

-- 
See you in Scottsdale, Arizona.
      http://xmlconnections.com/xml/xmlfall2001/speakers.asp#evandervlist
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
http://xsltunit.org      http://4xt.org           http://examplotron.org
------------------------------------------------------------------------