W3C home > Mailing lists > Public > public-i18n-ws@w3.org > October 2004

RE: Closing Issue 502 ( was RE: Issue 502 is closed )

From: Addison Phillips [wM] <aphillips@webmethods.com>
Date: Fri, 15 Oct 2004 08:48:59 -0700
To: <noah_mendelsohn@us.ibm.com>
Cc: "Martin Duerst" <duerst@w3.org>, "Martin Gudgin" <mgudgin@microsoft.com>, "I18n WSTF" <public-i18n-ws@w3.org>, <xmlp-comments@w3.org>, "Yves Lafon" <ylafon@w3.org>
Message-ID: <PNEHIBAMBMLHDMJDDFLHEEOAIKAA.aphillips@webmethods.com>

Hi Noah,

You are right that the word "replace" is problematic, even if I tend to
*think* it with regard to IRIs... :-)

It would be more correct to say:

> >> "NOTE: the use of the xs:anyURI type anticipates
> >> the adoption of IRIs in addition to URIs for the
> >> naming of resources"

In any case, the point here is to make explicit the possibility of IRI-like
stuff inherent in the anyURI type. Any text that accomplishes that task will
address our WG comment.

With regard to the word 'scheme', my objection to it is merely one of
aesthetics/readability. If it makes sense in the context of your document,
then that's fine. My concern in citing that word is that it seemed to
introduce unnecessary jargon into that sentence. It is, of course, a
judgement call that your group will need to make in light of the document as
a whole and should not be taken as a substantive comment.

Best Regards,


Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force

Internationalization is an architecture.
It is not a feature.

> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
> Sent: 2004年10月15日 8:02
> To: aphillips@webmethods.com
> Cc: Martin Duerst; Martin Gudgin; I18n WSTF; xmlp-comments@w3.org; Yves
> Lafon
> Subject: RE: Closing Issue 502 ( was RE: Issue 502 is closed )
> Addison Phillips writes:
> >> Also, I'm not sure that "schemes" is a very clear word choice here.
> >> Perhaps it would be better to say something like:
> >> "NOTE: the use of the xs:anyURI type anticipates
> >> the adoption of IRIs to replace URIs for the
> >> naming of resources"
> You may be right, though I think one can make the case that unless scheme
> names themselves use the new characters, the formulation we've
> proposed is
> both correct and adequate.  Once you have chosen a scheme name, it is
> indeed the scheme that determines (within the constraints of the URI RFC
> or IRI draft) what the rules for the rest of the name string are.  That
> said, I would have no objection to the following revision:
> "NOTE: the use of the xs:anyURI type anticipates the possibility that in
> future protocols will be developed that use IRI rather than URI
> naming for
> resources."
> Note that the IRI draft [1] says:
> "The protocol or format element where IRIs are used should be explicitly
> designated to be able to carry IRIs.  That is, the intent is not to
> introduce IRIs into contexts that are not defined to accept them. "
> I think it's premature to publish a recommendation suggesting, as you
> propose,  that IRI's would "replace URIs for the naming of resources".
> Even if IRI's are tremendously successful IRIs and URI's will coexist for
> a long time, and the protocols such as HTTP 1.1 that are URI-only will
> remain widely deployed for a long time.  The two will coexist, as ASCII
> and Unicode coexist in the computing world today.  Thus, I don't thing we
> need to get into the controversial claim that IRI's will "replace" URIs;
> for Representation headers it's enough to say that we are set to support
> IRIs when the protocols that we're caching choose to use them.
> Just my personal opinion.
> Noah
> [1] ftp://ftp.ietf.org/internet-drafts/draft-duerst-iri-10.txt
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
Received on Friday, 15 October 2004 15:46:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:39 UTC