RE: Proposed text for XMLBase

Hi Noah,

I've just taken a look at the text of XML Base [1]. The last paragraph of
the Introduction [2] states:

"The deployment of XML Base is through normative reference by new
specifications, for example XLink and the XML Infoset. Applications and
specifications built upon these new technologies will natively support XML
Base. The behavior of xml:base attributes in applications based on
specifications that do not have direct or indirect normative reference to
XML Base is undefined."

Section 3 "Relation to XML" of the current SOAP 1.2 part 1 editors draft [3]
(and earlier variants back to the current WD) it states:

"SOAP uses unqualified attribute information items with a local name of id
and a type of ID in the http://www.w3.org/2001/XMLSchema namespace to
specify the unique identifier of an encoded element. SOAP uses unqualified
attribute information items with a local name of href and a type of anyURI
in the http://www.w3.org/2001/XMLSchema namespace to specify a reference to
such a value, in a manner conforming to the XML Specification[11], XML
Schema Specification[8], and XML Linking Language Specification[12]."

Which results in normative references to XLink [4] and XML Schema Part 2 [5]
which itself normatively references XLink under its description of the
anyURI datatype [6]. 

Thus I believe that we are already in a situation when we at least have
indirect normative references to XML Base [1] and that its is implicit
already that the semantics of XML base be observed when dereferencing an
"...unqualified attribute item with a local name of href and a type of
anyURI...".

> "This version of the SOAP specification does not support the W3C XML Base
> Recommendation.  The xml:base attribute SHOULD NOT appear on the
> SOAP-ENV:Envelope, SOAP-ENV:Body, SOAP-ENV:Header, or SOAP-ENV:Fault
> elements;  processors receiving messages with such xml:base attributes
> SHOULD generate a XXXXXX fault (details TBD).
> 

Not sure... this doesn't outlaw xml:base within the things contained within
Envelope, Header, Body and Fault it does prevent an xml:base appearing high
up in the hierachy even if the relative URIs that use it could be much
further down the tree.

Seems to me that the problem is not so much the presense of xml:base at the
top level, but the presense of relative URIs in these high-level elements.
Not sure quite how to capture that. It seems to me that in the absense of
relative URI refs the presense of an xml:base is moot. In the presence of
href's deeper in a SOAP message, our current drafts commit us (implicitly)
to honoring any in-scope xml:base attribute - and it shouldn't matter that
it arise on one of the higher level elements. If xml:base handling needs to
go in for href handling, then you've probably done the lion's share of the
work.


> This specification provides no standard Base URI for the contents of the
> SOAP-ENV:Body or other header entries;  specifications for particular
> applications of SOAP, as well as specifications for transport bindings,
> header entries and/or body entries MAY define the interpretation of
> relative URI's within such body or entries. In the absence of such
> additional specifications, the resolution of relative URI's appearing
> within the contents of a body or other header entry is undefined.

> Relative URI's SHOULD NOT be used as  values for attributes or elements
> (such as SOAP-ENV:Actor, SOAP-ENV:EncodingStyle) defined by this
> specification;  if such values are used, their resolution to 
> absolute URI's is not defined by this specification.

Agree... although I guess I would prefer consistent treatment of anything
that carries a URI.

> Namespace declarations for the namespaces used in this  specification
(such 
> as http://www.w3.org/2001/06/soap-envelope) MUST be provided 
> as absolute URI's. 
>
> Element or attribute names qualified with relative 
> URI namespaces are not recognized as matching the absolute names mandated
by this
> specification.

Again, I'd agree that the use of absolute URIs should be encouraged in these
cases. I think I would be inclined to be 'forgiving' of relative URIs in the
presense of an appropriate xml:base attribute.

Regards

Stuart

[1] http://www.w3.org/TR/2001/REC-xmlbase-20010627/
[2] http://www.w3.org/TR/2001/REC-xmlbase-20010627/#introduction
[3] http://www.w3.org/2000/xp/Group/1/08/29/soap12-part1.html#reltoxml
[4] http://www.w3.org/TR/2001/REC-xlink-20010627/
[5] http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/
[6] http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#anyURI

> -----Original Message-----
> From: Noah_Mendelsohn@lotus.com [mailto:Noah_Mendelsohn@lotus.com]
> Sent: 29 August 2001 23:02
> To: xml-dist-app@w3.org
> Subject: Proposed text for XMLBase
> 
> 
> On the telephone call this afternoon, I took a "to do" to 
> propose text for
> the use of XMLBase with SOAP.  In researching the XMLBase 
> spec [1], the
> issue turned out to be a bit more subtle than I had realized: 
>  I believe
> there are three potential questions: (a) do we allow and 
> interpret per [1]
> the xml:base attribute?;  (b) in the absence of an xml:base 
> attribute, what
> do we say about the "base URI" for our document or entity as 
> used in [2]?;
> (c) can that base URI be determined or overriden by bindings 
> or additional
> specifications, such as SOAP+Attachments [3]?  I think the 
> sense of the
> call was "disallow (a), don't define (b), let other specs such as
> SOAP+Attachments do (c) ", so that's what I've tried to write.
> 
> I presume the editors would clean this up and integrate it 
> stylistically
> with the rest of the document:
> 
> ======================================================
> 
> BASE URI's and Relative URI Resolution
> --------------------------------------
> 
> "This version of the SOAP specification does not support the 
> W3C XML Base
> Recommendation.  The xml:base attribute SHOULD NOT appear on the
> SOAP-ENV:Envelope, SOAP-ENV:Body, SOAP-ENV:Header, or SOAP-ENV:Fault
> elements;  processors receiving messages with such xml:base attributes
> SHOULD generate a XXXXXX fault (details TBD).
> 
> This specification provides no standard Base URI for the 
> contents of the
> SOAP-ENV:Body or other header entries;  specifications for particular
> applications of SOAP, as well as specifications for transport 
> bindings,
> header entries and/or body entries MAY define the interpretation of
> relative URI's within such body or entries. In the absence of such
> additional specifications, the resolution of relative URI's appearing
> within the contents of a body or other header entry is undefined.
> 
> Relative URI's SHOULD NOT be used as  values for attributes 
> or elements
> (such as SOAP-ENV:Actor, SOAP-ENV:EncodingStyle) defined by this
> specification;  if such values are used, their resolution to 
> absolute URI's
> is not defined by this specification.
> 
> Namespace declarations for the namespaces used in this 
> specification (such
> as http://www.w3.org/2001/06/soap-envelope) MUST be provided 
> as absolute
> URI's.   Element or attribute names qualified with relative 
> URI namespaces
> are not recognized as matching the absolute names mandated by this
> specification."
> 
> ======================================================
> 
> Does this capture the sense of the group?  I'll leave it to 
> the editors to
> get out the SOAP-ENV stuff, which doesn't seem to be used in 
> the rest of
> the spec.
> 
> Sorry it turned out so clunky, but I think there are quite a 
> few edge cases
> to consider.  I wonder whether there will be any pushback for not more
> aggressively supporting a published W3C recommendation?  
> Otherwise, I agree
> with Paul that this is a reasonable compromise for 1.2.
> 
> [1] http://www.w3.org/TR/xmlbase/
> [2] http://www.w3.org/TR/xmlbase/#rfc2396
> [3] http://www.w3.org/TR/SOAP-attachments#SOAPReferenceToAttachements
> 
> --------------------------------------------------------------
> ----------
> Noah Mendelsohn                                    Voice: 
> 1-617-693-4036
> Lotus Development Corp.                            Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> --------------------------------------------------------------
> ----------
> 
> 
> 
>

Received on Thursday, 30 August 2001 10:09:10 UTC