RE: [xmlProfiles-29] TAG recommendation for work on subset of XML 1.1

>> As far as I know, SOAP hasn't expressed a requirement for anything.  

Looking back at the history of this issue [1], message [2] from David
Fallside officially describes the XMLP Working Group's rationale for
their use of a subset of XML.  And Mike Champion sent a message [3]
which gives the official W3C Web Services Architecture WG position
supporting the existence of this subset.

In addition your own message [4], gave an excellent rationale for why
SOAP used such a subset.

All of these inputs were important in convincing me as a TAG member to
support the TAG's recommendation [4] on this issue.  I invite
participants in this thread to review these earlier messages.

/paulc

[1] http://www.w3.org/2001/tag/ilist#xmlProfiles-29 
[2] http://lists.w3.org/Archives/Public/www-tag/2002Dec/0119.html 
[3] http://lists.w3.org/Archives/Public/www-tag/2003Jan/0212.html 
[4] http://lists.w3.org/Archives/Public/www-tag/2002Nov/0171.html 
[5] http://lists.w3.org/Archives/Public/www-tag/2003Jan/0418.html 

Paul Cotton, Microsoft Canada 
17 Eleanor Drive, Nepean, Ontario K2E 6A3 
Tel: (613) 225-5445 Fax: (425) 936-7329 
mailto:pcotton@microsoft.com

  

> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
> Sent: February 6, 2003 5:08 PM
> To: Henry S. Thompson
> Cc: richard@cogsci.ed.ac.uk; www-tag@w3.org
> Subject: Re: [xmlProfiles-29] TAG recommendation for work on subset of
XML
> 1.1
> 
> 
> Henry Thompson writes:
> 
> >> I made the proposal in the form I did to catch
> >> all and only what I understood the SOAP
> >> requirements to be, but I suspect you're
> >> right that just skipping the whole thing is better.
> 
> (speaking only for myself, not officially for the XMLP WG)
> 
> As far as I know, SOAP hasn't expressed a requirement for anything.
SOAP
> is an application of XML.  It so happens that a legal implementation
of
> SOAP will never put a DOCTYPE or a PI into a SOAP message.  It also
won't
> put in an <animal:elephant> tag as a child of the <soap:envelope>;
neither
> is allowed by SOAP.   As far as I'm concerned neither restriction
directly
> represents or suggests a requirement for anything to be included in
future
> XML specifications.
> 
> SOAP protocol bindings can use any representation they like as a wire
> format.  Some of those may not even have representations that could
> correspond to a DOCTYPE, implying that there is no way a receiver
could
> see one at all.  The interesting case, of course, is when the binding
> chooses to use an XML 1.x serialization, which is what the supplied
HTTP
> implementation does.   In that case, you could imagine a  buggy sender
> managing to transmit what is an otherwise legal SOAP message with a
> DOCTYPE or PI.  With the exception of one small exception that's
allowed
> only for performance, receivers receiving such representations must
> reflect errors >at the SOAP level<.  It's not an XML error, it's a
SOAP
> error.  Same as if an <animal:elephant> shows up.
> 
> So, nothing in this includes a "SOAP requirement" as far as I know.
Some
> who have seen these design decisions have come to their own
conclusions
> that a subset defined at the XML level would be better.  I'm not
> completely convinced, but that's what the TAG has quite appropriately
> suggested that the XML Activity, core group and/or Advisory Committee
> consider per the usual W3C process.   I'm glad to see that analysis
> starting, and I'm curious whether a subset, a conformance level, a new
> version of XML (deprecating the featues in question) or doing nothing
will
> prove on balance to be the best course.  Right now, I don't feel that
I
> know the answer, but I'm quite convinced that SOAP itself has no
> "requirement" in this area.  Thanks!
> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
> 
>

Received on Thursday, 6 February 2003 17:53:30 UTC