Re: [XRI] IRI thread

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