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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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


Subject: IRI vs URI Discussion Today (2010-09-13)


The chat room seemed to have crashed (and I was actually dropped by Skype in
an odd way), so the Intertube was flaky during our call.

Here is a follow-up to something that wasw on the chat.

1. In the discussion today, I said that Namespace URIs still have to be
URIs.  I believe that is true for the XML Namespaces 1.0 specification which
ODF relies on.  Steven Pemberton is correct that IRIs are now allowed in XML
Namespaces 1.1.

2. The problem is more complicated.  URIs *must* be expressed in a
restricted subset of the US-ASCII character repertoire (that is, a selection
of the characters in the Unicode Basic Latin set).  You can't put xsd:anyURI
on the wire because xsd:anyURI allows IRIs.  There are places on the wire
where a single-byte character encoding must be used so any non-URI IRI must
be mapped to the properly "escaped" (%-encoded) URI before transmission.
This is not a big problem for ODF so long as a consumer has access to a
resolver that accepts IRIs for resolution when the IRI is required to be for
a resource.  If not, the consumer must transform any non-URI IRI to its URI
mapping. 
  There is also an important question about when two IRIs are considered the
same or different (and this impacts URNs too and the potential resolution of
URIs as well).   It is conceivable (and permissible) that IRI references
"abc" and "a%62c" resolve to different resources (since they are different
URIs).   

3. Inside of a package, ODF determines the resolution between IRIs and
manifest:full-path entries and, most importantly, the Zip directory file
names in the case that the manifest:full-path entry is for a package file.
There is no standard for this case, but for whatever ODF provides.  (There
is a statement in the current ODF specification or perhaps a JIRA issue, as
I recall, that says the Zip specification settles the matter, but I have
been unable to find anything in the Zip specification that speaks to this
situation.)  That's why ODF needs to specify what the relationship is so
consumers can succeed and so producers can generate documents which can be
consumed properly.  It is probably the case that "abc" and "a%62c" would be
considered different in this case, but we should strongly discourage "a%62c"
from being used as the name of a package file.
   An interesting subtlety is that you can't be sure that a relative IRI
reference is a reference inside the package without attempting to resolve it
(technically, attempting to produce the absolute IRI/URI that is the
resolution of the IRI reference).  You don't need to attempt to find the
resource, but to know what its URI would be if it exists.  It appears that
this is entirely a matter for Part 3.

 - Dennis

Dennis E. Hamilton
------------------
NuovoDoc: Design for Document System Interoperability 
mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430 
http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org 



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