Subject: PaceIRI

From: Martin Duerst <[email-masked]>
Date: Tue, 11 Jan 2005 16:04:16 +0900

I have completed (as far as I'm concerned) PaceIRI.

The proposal is simple, namely to allow IRIs wherever the spec
currently allows URIs. I have given details of what needs to be
changed in the spec for that to happen. If anything is unclear,
I'm glad to help out the editors.

As far as I remember, the main objection on previous discussions
of IRIs was that the IRI spec was not yet approved. But it is
approved now. If there are other objections, please say so.

Regards,     Martin.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 11 Jan 2005 16:50:56 +0900

>I have completed (as far as I'm concerned) PaceIRI.

Just to help everybody to look at it faster, here is the URI/IRI:

http://www.intertwingly.net/wiki/pie/PaceIRI

Sorry I forgot.

---

From: Danny Ayers <[email-masked]>
Date: Tue, 11 Jan 2005 14:33:01 +0100

> http://www.intertwingly.net/wiki/pie/PaceIRI

I like it a lot in principle, my only concern is the dependency on an
IDN library (nicely put together Pace, btw). As noted this might be a
problem on small devices, but I would suspect that a proportion of
big-device implementors might be tempted to skip this step (if they're
anything like me, largely through ignorance of IRIs/IDNs in general).
Is there any way of reducing the impact here? Any deployment
experience from other application domains that can be drawn on?

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 11 Jan 2005 14:59:47 +0100

> I have completed (as far as I'm concerned) PaceIRI.

Looks good, but I dislike this point:

   «Do *not* replace element/attribute names that read 'uri'. This will
    lead to somewhat strange sentences as "The content of atom:uri in
    a Person construct MUST be a IRI." While this makes the spec somewhat
    strange to read in very few places, it will work out for users.»

I think all the 'uri' elements and attributes should jump on the next  
train to '/dev/null' and be replaced with 'href', ordinary Link Constructs  
or whatever. They stick out from the specification like dobermans in a  
duck-pond and just feels awkward and «not right».

With the introduction of IRI's, I think they are even more misplaced and  
there's better reasons for us to remove them completely.

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

---

From: Martin Duerst <[email-masked]>
Date: Tue, 11 Jan 2005 23:23:25 +0900

At 22:33 05/01/11, Danny Ayers wrote:
 >IDN library (nicely put together Pace, btw).

Thanks!

 >As noted this might be a

An IDN library consists of two parts: Nameprep, which is the part
needing the big tables, and punycode encoding, which is the encoding/
compression algorithm that is quite compact. My understanding is that
indeed some implementers are taking shortcuts with nameprep, although
they are definitely not supposed to do so according to the specs.

(One possibility where this would be possible even while strictly
conforming is for IRIs directly input on a mobile device, where
the manufacturer knows what characters can be input and can guarantee
that these don't cause problems with nameprep.)

Regards,    Martin.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 11 Jan 2005 23:25:57 +0900

I'm fine either way on attribute naming, but would like to point out
that this is an issue orthogonal to PaceIRI. The main point I was making
was that I was saying that changing the attribute names from 'uri' to
'iri' isn't necessary. But I would also be fine with a to change to
'iri' if that turned out to be the consensus on this list.
In summary, PaceIRI is about functionality, not about attribute names.

Regards,    Martin.

At 22:59 05/01/11, Asbj$B�S(Bn Ulsberg wrote:
 >   $B%)(BDo *not* replace element/attribute names that read 'uri'. This will
 >    strange to read in very few places, it will work out for users.$B%5(B
 >
 >duck-pond and just feels awkward and $B%)(Bnot right$B%5(B.
 >
 >Asbj$B�S(Bn Ulsberg     -=|=-    http://virtuelvis.com/quark/
 >$B%)(BHe's a loathsome offensive brute, yet I can't look away$B%5(B
 >