W3C home > Mailing lists > Public > www-archive@w3.org > September 2002

Editorial issue 264: Part 0 - section 6 - URIs

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Mon, 2 Sep 2002 12:03:13 -0700
Message-ID: <79107D208BA38C45A4E45F62673A434D0861826B@red-msg-07.redmond.corp.microsoft.com>
To: "Jean-Jacques Moreau" <moreau@crf.canon.fr>, "Marc Hadley" <marc.hadley@sun.com>, "Nilo Mitra" <EUSNILM@am1.ericsson.se>, "Noah Mendelson" <noah_mendelsohn@us.ibm.com>
Cc: "W3C Public Archive" <www-archive@w3.org>

The issue calls for indicating that information items carrying URIs as
values should be specified in section as having a type of xsd:anyURI.
After looking through the SOAP envelope defined EIs that carry URIs, all
have mention of being of type xsd:anyURI in section 5. It would
therefore seem as replication to add it in section 6 as well.

Schemas' definition of anyURI [2] explicitly calls out the relationship
between IRIs, URIs, and anyURI:

"The mapping from anyURI values to URIs is as defined in Section 5.4
Locator Attribute of [XML Linking Language] (see also Section 8
Character Encoding in URI References of [Character Model]). This means
that a wide range of internationalized resource identifiers can be
specified when an anyURI is called for, and still be understood as URIs
per [RFC 2396], as amended by [RFC 2732], where appropriate to identify

IMO, we have nothing to add regarding this issue as it is a) outside the
scope of SOAP and b) addressed by the schema spec already.

I don't think we have anything to say about how URIs can be carried
outside the SOAP Envelope. For example, how the request-URI is encoded
in an HTTP request is HTTP's problem and not ours. I do not support that
SOAP should see it as a requirement to dictate rules on SMTP, HTTP, etc.

In summary, I think we can close this issue with no action.

Henrik Frystyk Nielsen 

[1] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x264
[2] http://www.w3.org/TR/xmlschema-2/#anyURI
Received on Monday, 2 September 2002 15:02:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:31:53 UTC