Re: Issue 4 Proposed Resolution (was: why no doc type declarationand PIsin SOAP)

Thanks - and I also agree with the first part of [2] "XMLP and
applications of XMLP must be easy to deploy - especially in systems
already supporting XML technologies like XML namespaces and XML
schemas."

OK - given this requirement, it *will* be possible to overload even very
fast DOM-based parsers - I have a friend with this problem right now.

But I'd like to suggest that we can satisfy both requirements more
simply by standardizing on the XPath 1.0 data model. In other words we
specify that

[1]	conceptually, a soap implementation passes pre-parsed XML data to
and from its host applications. Just as in XSLT, all information about
the DTD, entities or original character quoting (eg CDATA sections) is
invisible to the implementation and cannot be restored in the output.

[2]	the choice of data structure for pre-parsed XML is up to the SOAP
implementor. It may be tree based (eg DOM) or event based (eg SAX), it
may be standard or non-standard. It could even be XML strings. The only
requirement is that the SOAP implementation must ignore or reject any
explicit DTD information in the model that it accepts, it must reject
any PI in the SOAP content, and it must pass through - without otherwise
acting on - any PI in the payload.

The consequences of this would be that generic SOAP processors could be
based on generic XML parsers, but that special purpose, high-performance
or low-resource SOAP processors could require appropriate input and
output. Coincidentally, there is a current article on "Writing SAX
drivers for non-XML data" at
http://www.xml.com/pub/a/2001/09/19/sax-non-xml-data.html

And anyone with XML documents that really need CDATA sections and DTD
entities to be preserved will just have to send them as attachments.

Francis.

Noah_Mendelsohn@lotus.com wrote:
> 
> >> could we list some of the use cases for
> >> XML Protocol?
> 
> Sure.  Some of this has been collected in the official requirements
> document[1].  One that is of crucial importance for my company's intended
> use is [2]:
> 
> "The design of the protocol architecture must be sensitive to the issues
> arising in the full spectrum of deployment environments ranging from
> resource constrained embedded devices (appliances) through high
> performance service engines."
> 
> I would strongly emphasize the need to support high performance service
> engines.  As I've said before, we're going to be competing with and
> attempting to displace binary protocols.  I would be very surprised if,
> for example, XSLT-based implementations were suitable in the highest
> performance settings.  In general, I would expect that for many
> medium-performance applications, off the shelf parsers, XSLT, etc. may
> play a role.  On the smallest devices, implementations will be customized
> for space and to minimize unnecessary features---indeed, some will support
> only one vocabulary ("getTrafficLightStatus") as opposed to
> general-purpose SOAP.  At the far extreme will be a variety of customized
> implementations designed to do only SOAP, and to do it with extremely high
> speed.  We certainly can't presume that general purpose off the shelf
> parsers will meet the needs of such high performance installations.
> 
> [1] http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/
> [2] http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#z306
> 
> ------------------------------------------------------------------------
> Noah Mendelsohn                                    Voice: 1-617-693-4036
> Lotus Development Corp.                            Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------------

Received on Tuesday, 2 October 2001 14:52:51 UTC