Re: I-D Action: draft-klensin-iri-sri-00.txt (three good reasons why not)

On 2012/07/10 5:03, Dave Thaler wrote:
> Also on the real substance of the SRI vs IRI discussion...
>
> Browsers today have an address bar.   That address bar today can often contain IRIs,
> which are more readable than URIs.   The SRI isn't amenable to that UI paradigm which
> was based on the URI-is-an-IRI principle.   In this proposal to get rid of that principle,
> it would be worth discussing UI paradigm principles, since the XML representation
> can't be easily rendered in such a box.   That means without IRIs, it seems one would either
> need a radically different paradigm, or one would need to always display the less-readable
> URI form.   I don't think always rendering the URI form would be any better for usability,
> so to me this proposal is tightly tied to the discussion of alternate rendering paradigms.

Yes, this is a very good point: SRIs are useless for presentation (in 
the browser bar, or as part of a textual reference, or in many other 
places).


SRIs are also unsuited for protocols/formats, because they would blow up 
and complicate syntax and processing needlessly. How would a format such 
as HTML or SVG use SRIs? Would anybody creating a new protocol or format 
choose lengthy and convoluted SRIs over URIs, even if they got told that 
SRIs were needed because of internationalization? Also, if SRIs are in 
XML, they fit well with XML, but how would I put it into a JSON document 
or an ASN1 document or any other format? Would we need a JSON version of 
SRIs, and an ASN1 version, and so on?

As an example, think about how to use an SRI in SVG. It's all XML, so 
it's relatively straightforward, but it's hopelessly lengthy. To just 
give an example, something that's now as easy as
    <use xlink:href="#étoile" />
(étoile is star in French; this works in SVG as of today!) would change 
to something like:
    <use>
      <href>
        <sri>
          <fragment>étoile</fragment>
        </sri>
      </href>
    <use>
(Minor details: I have taken the liberty to remove all namespace 
prefixes, and to remove the <uri> element (I don't understand why <sri> 
needs to be inside <uri>), and to not use any of <scheme>, 
<authority>,..., as the DTD would require because this is only a 
relative URI/IRI).


The third technical problem is that that SRIs don't solve the comparison 
problem. In another mail, John Klensin wrote:

 > I note that draft-ietf-iri-comparison seems intimately tied to
 > (1).  The intent behind (2) includes standardizing information
 > sufficiently that a simple XML structured comparison (i.e.,
 > ignoring irrelevant white space) should suffice without
 > identifier- or scheme-specific comparison rules.

It is essentially impossible to avoid scheme-specific comparison rules. 
The reason is that URIs/IRIs can include identifier components from 
arbitrary third-party identifier systems.

For an example, let's look at the tel: scheme 
(http://tools.ietf.org/html/rfc3966) for telephone numbers. 
tel:+1-201-555-0123 is equivalent to tel:+12015550123 (and 
tel:+12-0155-501-23 and a few other variants, just to show how this 
works). There are some other equivalence rules for tel: URIs, please see 
http://tools.ietf.org/html/rfc3966#section-4. Every time such an example 
is discovered, this may be addressed by creating the necessary 
element(s) in SRIs, but this is a task that will never end.


So my current conclusion is that SRIs are not suited for presentation, 
are ill-suited for inclusion into protocols/formats, and don't 
fundamentally help with processing problems such as comparison.

Regards,    Martin.

Received on Wednesday, 11 July 2012 10:05:54 UTC