RE: [office] Proposed change to Monday's agenda (IRI's versus URI's)

["Bastian, Waldo" <waldo.bastian@intel.com>]

+1

It's my understanding that for machine processing purpose IRI's offer the same functionality as URI's and that any IRI can be converted to a URI. However, implementations currently using URI's may not be able to process IRI's correctly. The main benefit of an IRI is that it allows for a more meaningful visual representation, in particular relevant in a CJK context. Given a URI, it's possible to convert it to a IRI, however the spec warns that "the IRI resulting from this conversion may not be exactly the same as the original IRI (if there ever was one)."

Assuming that we agree that it is desirable to support IRI's, the next question is how. Allowing IRI's where currently URI's are allowed may mean that software based on the OpenDocument v1.0 spec may not be able to process documents correctly that follow the updated spec. An alternative would be to introduce an optional attribute that contains the IRI in addition to the URI. The disadvantage of that approach is the additional complexity that that would introduce.

Some IRI and URI examples:

IRI in XML notation: http://example.com/𐌀𐌁&#x10302
Converted to URI: http://example.com/%F0%90%8C%80%F0%90%8C%81%F0%90%8C%82

IRI in XML notation: http://www.example.org/red%09rosé#red
Converted to URI: http://www.example.org/red%09ros%C3%A9#red

Cheers,
Waldo

________________________________________
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
Sent: Friday, January 20, 2006 9:03 AM
To: office@lists.oasis-open.org
Subject: [office] Proposed change to Monday's agenda (IRI's versus URI's)


I've been handed some unofficial feedback from the Japanese standards body, indirectly forwarded to me via IBM's Japanese subsidiary.  It appears that ODF's use of URI's rather than the new unicode IRI's (http://www.w3.org/International/O-URL-and-ident.html) has been received poorly, and may result in an unfavorable ISO vote from Japan. 

They are also questioning ODF's use of CSS3 and DOM level 3 events, since neither were formally adopted by the W3C.  The suggestion was to define necessary portions of these specs in the ODF spec, rather than by reference.  (IMHO, this seems like more of an editorial comment than a technical one.) 

I'm asking that we agree to take on this issue on Monday's call as a priority issue.  The next meeting of their standards group will be before the end of the month, so there is some urgency for the TC to state if and how they will address this issue before then, which could turn around their vote.   

I'm no expert in this area, but it seems a possible fix would be to allow an IRI every place in the spec where a URI is currently specified.  Would this cause any other issues in the specification?  Any implementation issues? 

The tricky part might be where we reference an external specification which has not been updated to allow IRI's. (SVG?  SMIL?).  If there is any data which is essentially shared between legacy URI-based standards and newer IRI-aware standards, then we'll need to be careful how they interface. 

Do we agree that this IRI issue is a legitimate concern with ODF documents in Japan (and potentially China, Korea, etc.)? 

Can I get some +1's for adding this to the agenda for Monday?

-Rob