W3C home > Mailing lists > Public > xml-dist-app@w3.org > December 2002

Re: Draft of position on SOAP's use of XML Internal subset

From: <noah_mendelsohn@us.ibm.com>
Date: Wed, 4 Dec 2002 21:12:32 -0500
To: rayw@netscape.com (Ray Whitmer)
Cc: fallside@us.ibm.com, xml-dist-app@w3.org
Message-ID: <OF09DDE1E0.DE688E25-ON85256C86.000C18B2@lotus.com>

Ray Whitmer writes:

> noah_mendelsohn@us.ibm.com wrote:
> >Still, we are aware of the tradeoff:  our decision to limit use of
> >constructions such as the internal subset is likley to reduce the
> >performance of and otherwise negatively impact implementations and
> >applications which would have otherwise been able to use certain 
> >purpose processors;  in many cases, those implementations will have to
> >resort to additional scanning and reporting to deal with the features 
> >we disallow.
> > 
> >
> The acknowledgement of the tradeoff is good.  You left out one phrase.
> Adapting to the subset of the infoset is potentially a significant part 
> of the added cost both in terms of performance and in terms of SOAP 
> being useful for general purpose messaging between clients and servers 
> with established XML infosets.

I guess I don't really understand what you're trying to
say here.  Adapting what to the subset?  Is there
something out there that had some XML lying around and you
want to use SOAP to send that fragment?  If that's your
concern, why is that not covered by the sentence I
included that said: "The tradeoff is that we have
somewhat complicated things for those who prefer to use
certain off-the-shelf processors, and for those who
want to insert arbitrary XML into SOAP messages (there
are many other problems doing that...a longer story
than we have time for here.)"

> If it just reported the errors that occurred when it tried to transport 
> it's own XML encoding of something, it would be a broken app, even if it 

> were compliant with SOAP.  It is something that others who discuss 
> subsetting XML should take into account.

There are several uses of the word "it" above, and I
think I'm losing your point.  I have a general sense
that you're again trying to get at transporting
arbitrary XML documents, or at least fragments, inside
of a SOAP body.  We know that's somewhat hard for
reasons that go beyond our subset.  Namespace prefixes
and defaults have to be handled carefully, if you do
plan to validate there can be issues with conflicting
id/idref, and maybe some others I'm not thinking of.  I
think it is roughly correct to say: "There are a
variety of factors that limit the degree to which
arbitrary fragments of existing XML can be "pasted"
intact into the body or header entry of a SOAP message;
for example default namespace declarations can cause
difficulties.  Nonetheless, our decision to disallow
PIs and entities somewhat further restricts the
fragments that can be successfully included."

For me, that point is not important enough to be worth
making, but if we get encouragement from the rest of
the group I'm not strongly against doing it.  ThI suggest
we see what others say.

> Perhaps you left out my wording "or adapting eliminated features" 
> because you didn't understand it.  I suggest it still belongs after the 
> word "reporting" in the above fragment.  This is a concrete suggestion.

Again, I think I have misunderstood, unless you're
talking about the points already discussed above.

> Thanks,
> Ray Whitmer

Thank you!


Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
Received on Wednesday, 4 December 2002 21:14:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:22 UTC