Re: 3023 update (was Re: Agenda TAG Telcon: 8th Nov 2004)

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) <EB2M-MRT@asahi-net.or.jp>

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
--------------------------------------