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


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] toxins/tocsins (was RE: [xml-dev] XQueryandDTD/Schema?)

[ Lists Home | Date Index | Thread Index ]
  • To: bryan <bry@itnisk.com>
  • Subject: RE: [xml-dev] toxins/tocsins (was RE: [xml-dev] XQueryandDTD/Schema?)
  • From: Eric van der Vlist <vdv@dyomedea.com>
  • Date: 05 Jul 2002 13:36:46 +0200
  • Cc: xml-dev@lists.xml.org
  • In-reply-to: <002d01c22414$40d28700$2001a8c0@bryans>
  • References: <002d01c22414$40d28700$2001a8c0@bryans>

On Fri, 2002-07-05 at 13:08, bryan wrote:
> Eric van der Vlist wrote:
> >One could even argue that SOAP is not using XML 1.0 but a XML like
> >markup language of its own: To be conform with SOAP you need to reject
> >XML documents using internal or external DTDs, ie to make a distinction
> >that neither the XML 1.0 recommendation nor the XML parsers I usually
> >use recognize!
> I think this would just make it an xml-based markup language. 
> I think languages that make such distinctions may become more frequent,
> where the language is parseable as xml but without additional
> constraints it will be non-parseable as its purported language. To me,
> from just a pragmatic perspective, this is not much different than
> having languages like svg.

No, I thing that there is a huge difference between these two

To read a SVG document I can use any conform XML parser and I can
validate the document using any XML schema language or XSLT

If I use a conform XML parser I am unable to check that a document is a
valid SOAP document using a XML schema language or a XSLT

And parsers reporting errors when the meet a DTD as required by SOAP
should not be considered per the XML 1.0 rec which says:

"Non-validating processors are required to check only the document
entity, including the entire internal DTD subset, for well-formedness.
[Definition: While they are not required to check the document for
validity, they are required to process all the declarations they read in
the internal DTD subset and in any parameter entity that they read, up
to the first reference to a parameter entity that they do not read; that
is to say, they must use the information in those declarations to
normalize attribute values, include the replacement text of internal
entities, and supply default attribute values.]"

In other words, I can't process a SOAP document with a conform XML
parser and a parser which processes a SOAP document as specified by the
SOAP specification isn't a conform parser, ie I need a different set of
tools to process XML and SOAP documents.

>  I seem to remember there was an early document concerning UBL where it
> was discussed having IDREFs being forward only, haven't looked at
> anything recently so unsure if that was adopted or not. This seems like
> another case of this thing, and it did not seem at the time anything in
> particular to worry about.

Shouldn't we worry to need a different set of tools for each new "XML

To me, that's the end of the interoperability between XML applications
and probably the end of XML too since for each application taken
separately there are always better solutions than XML!


See you in San Diego.
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema


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

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