(BI'm fine either way on attribute naming, but would like to point out
(Bthat this is an issue orthogonal to PaceIRI. The main point I was making
(Bwas that I was saying that changing the attribute names from 'uri' to
(B'iri' isn't necessary. But I would also be fine with a to change to
(B'iri' if that turned out to be the consensus on this list.
(BIn summary, PaceIRI is about functionality, not about attribute names.
(B
(BRegards, Martin.
(B
(BAt 22:59 05/01/11, Asbj$B�S(Bn Ulsberg wrote:
(B >On Tue, 11 Jan 2005 16:04:16 +0900, Martin Duerst <[EMAIL PROTECTED]> wrote:
(B >
(B >> I have completed (as far as I'm concerned) PaceIRI.
(B >
(B >Looks good, but I dislike this point:
(B >
(B > $B%)(BDo *not* replace element/attribute names that read 'uri'. This will
(B > lead to somewhat strange sentences as "The content of atom:uri in
(B > a Person construct MUST be a IRI." While this makes the spec somewhat
(B > strange to read in very few places, it will work out for users.$B%5(B
(B >
(B >I think all the 'uri' elements and attributes should jump on the next
(B >train to '/dev/null' and be replaced with 'href', ordinary Link Constructs
(B >or whatever. They stick out from the specification like dobermans in a
(B >duck-pond and just feels awkward and $B%)(Bnot right$B%5(B.
(B >
(B >With the introduction of IRI's, I think they are even more misplaced and
(B >there's better reasons for us to remove them completely.
(B >
(B >--
(B >Asbj$B�S(Bn Ulsberg -=|=- http://virtuelvis.com/quark/
(B >$B%)(BHe's a loathsome offensive brute, yet I can't look away$B%5(B
(B >
