[XRI] IRI thread

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.

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.

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
>>
>>
>>
>>
>>
>>
>>
>