OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: AR 027 - FW: UDDI: Interop issues relating to the XML Schema datatype anyURI




As reported today during the telecon, find below a response from Martin Düerst, W3C Internationalization Activity Lead. This response was received following a mail I sent to the XML Working Group, I18N and URI activity leads on the interop matter identified by Andrew [1] relating to internationalized URIs and its use with the anyURI datatype.

I cannot comment on the current recommendation and its impact on the issue Andrew identified as I have not yet reviewed draft-duerst-iri-06.txt (which appears to be a long draft - ugh).
 
Luc
 
[1] http://www.oasis-open.org/committees/download.php/5649/TC_FTF_Minutes-V1.7-20040210-12.htm#_Toc65400705

-----Original Message-----
From: Martin Duerst [
mailto:duerst@w3.org]
Sent: Monday, March 01, 2004 09:15
To: Luc Clement; cmsmcq@w3.org; connolly@w3.org
Cc: 'Von Riegen, Claus'; 'Rogers, Tony'; Tom Bellwood
Subject: RE: UDDI: Interop issues relating to the XML Schema datatype anyURI

Hello Luc,

Many thanks for your inquiries about IRI and anyURI. I was not aware of the as-of-yet somewhat patchy support. Can you give examples of tools that support and don't support anyURIs? This should definitely be fixed, and maybe we should create some tests.

Regarding the schedule of what's currently draft-duerst-iri-06.txt, we are thinking that we are very close to submitting it to the IETF.
Please watch
http://www.w3.org/International/iri-edit/.

Regards,    Martin.

At 14:48 04/02/28 -0800, Luc Clement wrote:
>"urn:schemas-microsoft-com:office:office">
>Correction of email address for Dan Connolly to
><
mailto:connolly@w3.org>connolly@w3.org
>
>
>----------
>From: Luc Cl駑ent [
mailto:luc@iclement.net]
>Sent: Saturday, February 28, 2004 14:45
>To: 'cmsmcq@w3.org'; 'duerst@w3.org'; 'dan@w3.org'
>Cc: 'Von Riegen, Claus'; 'Rogers, Tony'; Tom Bellwood
>(bellwood@us.ibm.com)
>Subject: UDDI: Interop issues relating to the XML Schema datatype
>anyURI
>
>To:     M. Sperberg-McQueen,Chair XML Schema Working Group,
><
mailto:cmsmcq@w3.org>cmsmcq@w3.org
>         Martin D・st,Internationalization Activity Lead, 
><
mailto:duerst@w3.org>duerst@w3.org
>         Dan Connolly, URI Activity Lead, [lc] 
><
mailto:connolly@w3.org>connolly@w3.org
>
>Gentlemen,
>
>I'm writing to you as the Secretary of the OASIS UDDI Spec Technical
>Committee. UDDI makes use of anyURI in elements that are intended to be
>directly invokable (e.g. discoveryURL and overviewURL).  We have
>encountered interoperability issues with respect to internationalized
>URIs. Without going into specifics, some schema processor
>implementations only accept characters defined in RFC2732, whereas
>others accept Unicode characters that would result in valid RFC2372
>URIs if processed by the algorithm defined by XLink. This affects how
>such elements need to be handled by a client, persisted by a UDDI node, and replicated.
>
>The TC is considering a number of alternatives (see extract below of
>minutes [1]), ranging from requiring the use (by a client) of the more
>restrictive case - RFC2732 - and encoding of Unicode characters that
>fall out of its range, to allowing support (by a server) of the full
>breath of Unicode characters in elements of type anyURI. There are of
>course of other options and different means of going about addressing
>this as described in the minutes.
>
>We are trying to assess how best to tackle this issue by understanding
>the current state of work on internationalized URIs in XML Schema. What
>is the current state of affairs with anyURI in XML Schema as it relates
>to internationalized URIs? What ongoing activities should we know of
>that may help us determine what our best immediate and longer term
>course of action are? Any guidance would be most appreciated.
>
>Thanks in advance for your time and consideration.
>
>Luc Cl駑ent
>Secretary, OASIS UDDI Spec TC
>
>[1] Minutes of the UDDI Spec TC FTF Meeting 20040210-12,
><http://www.oasis-open.org/committees/download.php/5649/TC_FTF_Minutes-
>V1.7
>-20040210-12.htm#_Toc65400705>
http://www.oasis-open.org/committees/download.
>php/5649/TC_FTF_Minutes-V1.7-20040210-12.htm#_Toc65400705
>
>Excerpt from [1]:
>
>5.5 V3 Issue: discoveryURL & overviewURL
>
>Andrew submitted the following item for discussion:
>
>During the course of implementing a V3 registry, we have found that the
>discoveryURL and overviewURL could cause interoperability issues due to
>the current state of schema assessment performed by various
>implementations on the XML Schema datatype anyURI.
>
> From the XML Schema specification, it says it is lexically valid after
> applying the algorithm from XLink which could mean that certain
> characters outside of US-ASCII would be valid as long as they can be
> encoded later per XLink section 5.4.
>
>Lexical representation
>
>The キlexical spaceキ of anyURI is finite-length character sequences
>which, when the algorithm defined in Section 5.4 of [XML Linking
>Language] is applied to them, result in strings which are legal URIs
>according to [RFC 2396], as amended by [RFC 2732].
>
>from XLink:
>
>Some characters are disallowed in URI references, even if they are
>allowed in XML; the disallowed characters include all non-ASCII
>characters, plus the excluded characters listed in Section 2.4 of [IETF
>RFC 2396], except for the number sign (#) and percent sign (%) and the
>square bracket characters re-allowed in [IETF RFC 2732]. Disallowed
>characters must be escaped as follows:
>
>1.        Each disallowed character is converted to UTF-8 [IETF RFC 2279]
>as one or more bytes.
>
>2.        Any bytes corresponding to a disallowed character are escaped
>with the URI escaping mechanism (that is, converted to %HH, where HH is
>the hexadecimal notation of the byte value).
>
>3.        The original character is replaced by the resulting character
>sequence.
>
>The result of the indirection in this definition is that some
>implementations of anyURI accept only characters defined in RFC2732,
>whereas others accept the Unicode characters that would result in valid
>RFC2372 URIs if processed by the algorithm in XLink.
>
>The XML Schema group has acknowledged that for I18N reasons, the schema
>allows Unicode characters in anyURI and that for now clients should
>transform them to access/invoke the resource.  I would like to know if
>the UDDI TC desires this flexibility as well.  If the UDDI TC desires
>that the client be able to specify Unicode without escaping the
>non-ASCII characters, it may be beneficial for short term
>interoperability of UDDI implementations to change to the string
>datatype as is already the case with access points.  Another option
>would be to place a post schema assessment restriction requiring that
>the publisher escapes the URIs per
>RFC2372 prior to publication.
>
>Minutes:
>
>About half of the clients have implemented this differently - we should
>expect to see interop problems as a result.  It generally remains the
>client's responsibility to convert URI's into a URL that can support
>dereferencing via an internet call.  Also, do we want UDDI to have
>directly invokable URI's, or should we expect clients to transform
>these URI's before using them?  Clients such as Microsoft IE typically
>do such transformations automatically, etc.  If we change the type to a string we
>get over the interop issue.   Another option is that we mandate they be
>pre-transformed.  Yet another option is that we can leave this matter
>alone and expect that this issue will have been resolved in the next 2 yrs.
>
>Treating all of these URLs as strings would make everything consistent,
>though consideration should be made to convert the accessPoint into an
>anyURI instead of a string.
>
>Daniel suggested creating a new UDDI specific URI type which is
>actually invokable, inheriting from anyURI.  We'd describe the type in
>the spec indicating it is invokable.  This would of course require us
>to version the spec when W3C & IETF finishes its work on IRIs.
>
>At issue is whether we make UDDI independent of other specs, or whether
>we accept impact of changes in other specifications on UDDI
>implementations at any given time.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]