Murata Makoto writes:
> Noah Mendelsohn writes:
>
> > The draft I sent to Chris Lilley and Dan Kohn on October 6 says:
> >
> > 7. XML Versions
> >
> > application/xml, application/xml-external-parsed-entity, and
> > application/xml-dtd, text/xml(deprecated) and
> > text/xml-external-parsed-entity(deprecated) are to be used with
[XML]
> > and [XML1.1]. In all examples herein where version="1.0" is shown,
> > it is understood that version="1.1" may also be used, providing the
> > content does indeed conform to [XML1.1].
> >
> > Specifications and recommendations based on or referring to this
RFC
> > SHOULD indicate any limitations on the particular versions of XML
to
> > be used. For example, a particular specification might indicate:
> > "content MUST be represented using media-type application/xml, and
> > the document must either (a) carry an xml declaration specifying
> > version="1.0" or (b) omit the XML declaration, in which case per
the
> > XML recommendation the version defaults to 1.0"
>
> Is this good enough?
Yes, thank you. As I recall, this is exactly what we agreed. Furthermore,
the media type description for application/soap+xml takes advantage of the
suggestion in the second paragraph above, indicating [1]:
This specification defines the media type
"application/soap+xml" which can be used to
identify SOAP 1.2 message envelopes that have
been serialized with XML 1.0. Such
serializations are useful as the basis of "wire
formats" for SOAP 1.2 Protocol Binding
Specifications [W3C.REC-soap12-part1-20030624],
or in other situations where an XML
serialization of a SOAP envelope is required.
The "application/soap+xml" media type
explicitly identifies SOAP 1.2 message
envelopes that have been serialised with XML
1.0; message envelopes with a different SOAP
namespace version or using another XML
serialisation MUST NOT use it.
Note that application/soap+xml is used by the particular HTTP binding
described in SOAP part 2 [2]. Bindings to other SOAP "transports" may but
need not use the above media type, with its XML 1.0 restriction. So, XML
1.1 may be used with SOAP, just not with the particular binding that we've
offered as a suggestion for connecting with HTTP.
FYI: SOAP envelopes begin life as synthetic infosets. Due to the lack of
availability of XML Schema support for XML 1.1 and the reliance of SOAP on
a normative schema for its envelope, SOAP envelopes are for the moment
restricted to Infosets that have only XML 1.0 constructs. Accordingly,
there is never a case where one has a SOAP envelope that fails to
serialize merely because the media type is limited to XML 1.0; the
content being serialized is already restricted to work with XML 1.0.
There are some other challenges. Because all SOAP nodes currently agree
on the content rules for SOAP envelopes, all SOAP implementations
interoperate. There is never a situation in which a "legacy" XML
1.0-only intermediary stuck in the middle of a network path prevents
transmission of legal XML 1.1 SOAP envelopes. When and if XML 1.1 support
is allowed, that will change, as there will surely be XML 1.0-only
implementations out there for a long time.
Also, the new MTOM support provides a means of efficiently carrying XML
1.1 fragments or documents as opaque encapsulated content in a SOAP 1.2
envelope; because it's an encapsulation protocol, MTOM does not eliminate
the restrictions on SOAP's own constructs. MTOM information is data as
far as the SOAP processing model is concerned.
Anyway, I believe it's fair to say that the XMLP working group may revisit
the restriction to XML 1.0 at such time as XML Schema support for XML 1.1
becomes available. We were well along on the path to supporting both XML
1.0 and XML 1.1 when we realized that lack of Schema support was a serious
problemj for us.
With my schema hat on, I can tell you that the WG is considering
directions for XML 1.1 support, and may have some interim advice in the
near- to medium-term. I'm less sure when we'll see normative support.
Given that the schema WG is exploring these questions in member-only
discussions, I'd prefer not to go further without permission of the chair.
I don't think there's anything sensitive about our discussions, it's just
W3C process that dictates I not make them public without explicit
permission of the group. Hope that non-members will understand. Members
should watch for minutes of the just completed Schema F2F in Redwood
Shores.
> > Noah
>
> However, this interim draft has not been published yet. To keep the
> ball rolling, I am going to submit this I-D soon.
>
> Cheers,
>
...and to you!
> --
> MURATA Makoto (FAMILY Given) <[email protected]>
Noah
[1] http://www.rfc-editor.org/rfc/rfc3902.txt
[2] http://www.w3.org/TR/soap12-part2/#soapinhttp
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.