The Web Services Architecture WG position on XML profiling/subset ting

The Web Services architecture WG wishes to makes its position known to the
TAG on issue xmlProfiles-29 " When, whither and how to profile W3C
specifications in the XML Family".  As you know, this issue came to your
attention because SOAP (since its inception) has forbidden DTD internal
subsets, external DTD references, and processing instructions.  The reasons
for this are very well stated in
http://lists.w3.org/Archives/Public/www-tag/2002Dec/0119.html and.  We do
wish to state this working group's opinion that it is vital for the W3C to
take action to formally recognize the profile of XML that is commonly used
in Web services applications so as to promote the use of generic XML tools
in web services applications. We strongly believe that the "muddle through"
option being advocated by some on the www-tag list will set into concrete a
situation that is sub-optimal at best for the Web services community and
bound to foster a disconnect between the Web services and XML communities.
 
One solution, which the SOAP community has pioneered, is to "bless" a
profile of XML technologies as the foundation on which to build.  In the
case of SOAP, that includes a subset of XML 1.0 that allows composability of
XML messages,  plus the Namespaces spec, and the XML Base spec.   It would
be very desirable to see this profile given authoritative status by the W3C
so that XML tool developers could either develop parsers, etc. that are
optimized for this profile or allow the user to check conformance to the
profile.   This alleviates a problem today in which a SOAP message can be
valid according to the SOAP 1.2 schema but be illegal with respect to the
SOAP specification itself, e.g., if it contains a DTD internal subset.  The
current situation hinders interoperability, the reuse of generic XML tools
for Web service development, and sows confusion among the users.

One issue that SOAP 1.2 "punts" on (as do some other W3C specifications,
including DOM Level 2 and XSLT) is the question of how an "id" attribute is
defined in the absence of a DTD and without insisting on a schema processing
step.  Some officially sanctioned mechanism -- ID attributes in the XML
namespace ("xml:id"), an ID attribute declaration mechanism suppported in
the core of XML (e.g. "xml:idattr="ID"), or even an approved convention that
"ID", "id" and "Id" are all to be considered ID attributes unless the ID
attribute is specified by some other mechanism, seem like viable options at
this point.

Another issue of concern to the Web services community is xml:base.  SOAP
uses URIs for some identifiers including, but not limited to, values of the
encodingStyle (see 5.1.1 SOAP encodingStyle Attribute) and role (see 5.2.2
SOAP role Attribute) attribute information items. SOAP does not define a
base URI but relies on the mechanisms defined in the XML Base specification
and [RFC 2396] for establishing a base URI against which relative URIs can
be made absolute.  Thus, it is important for an XML processor used to
process SOAP messages to implement the xml:base specification, and this
should be reflected in the WS-friendly XML profile.

Additional features that would make XML more widely useful for Web services
have been advocated by some members of the Web Services Architecture WG.  We
note that they are not supported by the same overwhelming majority of the
the WG endorsing this message.  For example, it would be very desirable to
formalize a profile of the XML schema specification that is suitable for web
services applications; it would be desireable to further enhance the
composability of XML documents, e.g. by a standardized mechanism allowing an
XML parser to handle files containing multiple well-formed XML fragments but
without an enclosing element, and to allow multiple character encodings to
be used within a single XML document.  We realize that there are practical
challenges preventing these features to be agreed upon quickly, and they go
beyond the sentiment to NOT add any additional features in the profile
discussion, and suggest merely that these be considered at some point in the
future.

There is currently no strong opinion within the WSA WG on how the profiles
should be specified, whether in a future rev of the XML spec or an adjunct
specification. The important thing to us is not the specific mechanism or
even the details of a profile, but encouraging a widely-adoped convention
that will allow XML tools to guarantee conformance with the profile of XML
that has come into widespread use in the Web services community.

Received on Friday, 17 January 2003 03:36:35 UTC