- From: Felix Sasaki <fsasaki@w3.org>
- Date: Mon, 21 Jul 2008 20:03:29 +0900
- To: John Bradley <john.bradley@wingaa.com>
- CC: "Henry S. Thompson" <ht@inf.ed.ac.uk>, "Booth, David (HP Software - Boston)" <dbooth@hp.com>, www-tag@w3.org, Martin Duerst <duerst@it.aoyama.ac.jp>
Hi John (putting Martin Duerst into the loop), sorry for my late reply, a mixture of holiday and travel is my excuse. John Bradley さんは書きました: > Hi Felix, > > Thanks for the input. > > IRI is related to the xri: scheme discussion. > > One of the reasons (perhaps not the only reason) people don't want > xri: to be a scheme is the concern that the IRI form of XRI will be > used for XML namespace declarations. > > This seems to be a general problem not specific to XRI. > > There is a community that believes that all XML > namespace declarations should be http: URLs unless there is some > super compelling reason to do something else. I may even fall into > that camp myself. > > I think David Orchard and I agree that if someone wants to use XRI > versioning or something else in a XML namespace declaration they MUST > use the HXRI form that way it is a just a normal URL from a XML > processing perspective. > > I have put this to members of the XRI-TC and the above > is generally uncontroversial. > > The question becomes how do you stop people from using the xri: scheme. > > One effective way is to not issue the scheme. This seems to be > the preferred solution by some W3C TAG members. > > The perhaps unintended byproduct is that without a scheme we can't > represent a XRI as a IRI in other places that might be more > appropriate like a UI. > > One thing we could still do is use the IRI form of the HXRI this would > be a normal IRI with the http: scheme. > > This has certain problems in that we have specified > NFKC normalization rather than the NFC normalization that http uses > for the path. From my understanding (which is mainly based on discussion with Martin) NFKC includes NFC. The main difference is that NFKC is getting rid of characters that have a compatibility decomposition, see e.g. appendix J of http://www.w3.org/TR/2008/PER-xml-20080205/#sec-suggested-names So you could require NFC, add a recommendation like "Characters which have a compatibility decomposition (those with a "compatibility formatting tag" in field 5 of the Unicode Character Database -- marked by field 5 beginning with a "<") should not be used in names. This suggestion does not apply to #x0E33 THAI CHARACTER SARA AM or #x0EB3 LAO CHARACTER AM, which despite their compatibility decompositions are in regular use in those scripts." and be fine. > > Without a scheme and defining our IRI transforms against the scheme > IRI is certainly more awkward to deal with. > > I want to know if there are opinions for or against having a IRI form > of a HXRI lets call it a IHXRI. I don't see the need to make a separation between identifiers for namespaces and others, but I won't oppose to it. I do see a value to allow identifiers which include non-ASCII characters. Regards, Felix. > > Your feedback is greatly appreciated. > > Regards > John Bradley > OASIS IDTRUST-SC > http://xri.net/=jbradley > 五里霧中 > > PS my 漢字 sucks I cheat and get Nat Sakimura to translate if I need to:) > > > > > On 17-Jul-08, at 3:41 AM, Felix Sasaki wrote: > >> Hello John, >> >> >> John Bradley さんは書きました: >>> I want to rase a question to the group in general. >>> >>> The XRI-TC has defined 7 forms for the representation of XRI, and >>> the transformations between them. >>> >>> I reviewed them in response to a question by David Orchard on this >>> thread July 14. >>> >>> Three of those forms involve using the xri: scheme indicator at the >>> start. >>> >>> Thee forms one scheme? How can the be? >>> >>> I think this question is causing some of the push back. >>> >>> People are concerned that strings that have a valid scheme prepended >>> are not valid URIs. >>> >>> This is true, however this situation is NOT the invention of the >>> XRI-TC, nor is it unique to XRI. >>> >>> The XRI-TC followed RFC 3987 to allow internationalized forms of XRIs. >> >> I personally think that this is the right approach (without judging >> XRIs in general). >> >>> >>> XRI has two IRI forms: >>> 1. IRI-Normal This allows UTF-16 Though UTF-8 is recommended >>> 2. IRI-UTF8 A more restrictive form allowing only UTF-8 >>> >>> The one difference between a http: IRI and a xri: IRI is that XRI >>> specifies the more restrictive NFKC Normalization across the entire >>> string, Where http uses two separate normalization's PUNyCODE for >>> the Authority segment and NFC for the path, and don't ask about the >>> query string:) >>> >>> XRI has one and only one URI form. The transforms to and from this >>> form are clearly defined. >>> This is the form that is uses anyplace a URI is required. A IRI is >>> NOT a URI, it would be WRONG to use a IRI in an XML document for >>> name-spacing. >>> >>> The XML specs are clear and unambiguous use a URI. >>> >>> XRI clearly differentiates between the two things. >>> >>> I am currently getting surprising push back on defining IRIs for use >>> with openID. With ICANN's recent decisions on DNS http: IRIs are coming. >>> >>> If we had something other than a URI scheme to identify a IRI that >>> might address some of the issues. >>> >>> I am tempted to ask if people are opposed to IRI RFC3987 in some >>> way? However that would probably be impolitic. >>> >>> Yes there are many open question regarding XRI's fundamental right >>> to exist. >>> >>> However is there an issue around our use of IRI that is going unspoken? >>> >>> If there was no IRI form would anyone think that having a xri: >>> scheme was a more reasonable thing. >> >> I don't see any issues and, seeing no responses to your question in >> this thread I think others agree silently with that. >> >>> I don't want to dismiss the opinion expressed on this thread that >>> having a scheme is the appropriate way to represent a protocol other >>> than http being used for a URI. >>> >>> I think there are three major options at this point: >>> 1. Use a URI scheme to indicate that a string is an XRI, Plus HXRI >>> for backwards compatibility with browsers and click behavior. >>> 2. HXRI with special coding in the authority segment >>> 3. HXRI with special encoding in the Path. >>> >>> I suppose there is a fourth possibility which is only using xri: on >>> the URI form and not having an IRI form. >>> >>> I suppose we could always define a http: IRI form? >>> >>> So I would appreciate your thoughts on how IRI plays into this >>> discussion on XRI. >> >> IMO IRIs are unrelated to the main topic of this discussion. >> >> Felix >> >>> >>> Best Regards >>> John Bradley >>> OASIS IDTRUST-SC >>> http://xri.net/=jbradley >>> >>> >>> >>> >>> >>> >>> >> >
Received on Monday, 21 July 2008 11:04:26 UTC