Subject: Re: Interoperability and canonicalization (Was: atom:id - comparison and generation)

From: Bill de hÓra <[email-masked]>
Date: Wed, 01 Sep 2004 11:05:21 +0100

Dare Obasanjo wrote:

> The fact that Atom will require an ID attribute is a
> step in the right direction. But a bigger step is
> ensuring that all clients use THE SAME ALGORITHM for
> comparing IDs. 

+1. This is one reason why I started a thread on generators and 
comparators. The atom:id functions are at least if not more 
important than the atom:id format.

The language lawyer in me says this could be phrased as a data 
quality issue and not an interop issue, but irregardless, if 
implementors have guidelines that they aren't required to implement 
for atom:id, end-user experience will be all the poorer.

cheers
Bill

---

From: Danny Ayers <[email-masked]>
Date: Thu, 2 Sep 2004 19:47:36 +0200

> for atom:id, end-user experience will be all the poorer.

I'd like to hear more about the problems Dare encountered. One
particular aspect that bothers me a little about making a particular
client-side comparison algorithm a MUST is that the RFC describes a
ladder of techniques, so more accurate comparison according to that
spec would be ruled out. A whole tranche of (non-canonicalized) id
comparisons would systematically produce false negatives. Without
knowing more, it's hard to judge whether this would be an acceptable
trade-off.

Without further information on what problems will be avoided and what
specific client behaviour is being proposed it's hard to judge the
cost/benefit for mandating *anything* at the consumer. Other problems,
such as that Dare identified at [1] (comparing different URIs that are
intended to identify the same resource)  may also need to be
considered.

As I'll maintain until I've heard a convincing counter-argument, many
of the potential problems of URI comparison evaporate if ids are
canonicalized on creation (and maintained verbatim). In implementation
terms this is relatively low-cost. Seems to me that its better to
start with predictable URIs than try and deal with ambiguities further
down the line.

Cheers,
Danny.

[1] http://www.imc.org/atom-syntax/mail-archive/msg09211.html 

-- 

http://dannyayers.com

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Sep 2004 20:16:46 +0200

Danny Ayers wrote:
 > ...

No, they would *correctly* produce negatives.

At some point, we need to decide what the comparison is. If it's 
char-by-char, then we need to accept that "http:://example.com" and 
"HTTP://example.com" *indeed* are different IDs. In which case it really 
doesn't make sense to complain about "false" negatives. They aren't.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Danny Ayers <[email-masked]>
Date: Thu, 2 Sep 2004 21:00:19 +0200

> doesn't make sense to complain about "false" negatives. They aren't.

The sense comes from the notion of *Uniform* Resource Identifiers.
http://example.com and HTTP://example.com identify the same resource
according to rfc2396bis, which explicitly states that the scheme part
is case-insensitive. If a comparator decides they aren't equivalent,
then that's a false negative according to the definitions in
rfc2396bis. Sure, as you suggest, we could use an Atom-specific
definition of equivalence to override that. But I'd argue that would
lose the advantage of uniformity - browsers for example generally see
the scheme case-insensitive. There are precedents for overriding
equivalence in this way, but I don't see what Atom would have to gain.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 03 Sep 2004 01:51:53 +0100

Danny Ayers wrote:

> is case-insensitive. 

Ah, good play on words, but I'm not buying that :)

See if you can get this to run on anything:

<xsl:stylesheet xmlns:xsl="HTTP://www.w3.org/1999/XSL/Transform"
      version="1.0">
   <xsl:output method="xml" omit-xml-declaration="yes"/>
   <xsl:strip-space elements="*"/>
   <xsl:preserve-space elements="codeListing sampleOutput"/>
   <xsl:template match="@*|node()">
    <xsl:copy>
     <xsl:apply-templates select="@*|node()"/>
    </xsl:copy>
   </xsl:template>
</xsl:stylesheet>

;)

One can make a good arguement that the sense of URI use in XML is 
closer to atom:id uses cases than protocol specific stuff required 
by rfc2396bis and parent.

> Sure, as you suggest, we could use an Atom-specific

Use of string compares on clients or any data sinks is potentially a 
win. Do we really want to use rfc2396bis rules to /compare/ 
atom:ids? Warning: coding at this stuff in anger could result in an 
object hierarchy for URIs with GenericURI sitting at the top... 
maybe rfc2396bis makes all this easier now, but it wasn't so a few 
years back.

cheers
Bill

---

From: Danny Ayers <[email-masked]>
Date: Fri, 3 Sep 2004 19:38:23 +0200

> by rfc2396bis and parent.

Hmm, I think I'll introduce the word 'scope' here. As used in
namespaces, the identifier is carried across the whole of the
vocabulary. In Atom it's localised to individual items. The usage
patterns are wildly different: several thousand URIs have been passed
out of my little blog's RSS feed, yet I doubt whether more than a
couple of dozen or so namespaces have been used in all the RSS 1.0 in
the world. Bit of fresh data: in the chatlogs[1]  of the Galway FOAF
conference yesterday a 'modest' crawl of FOAF profiles was mentioned
that covered 274,00 distinct individuals, yielding 6.73 million
triples and 196 namespaces. (I for one was surprised how high that
last figure was).

But ok, when you stretch out into RDFS/OWL Full there is overlap with
the use of URIs as individual identifiers and their use in namespaces,
so I guess that's some justification for treating them the same.

> maybe rfc2396bis makes all this easier now, but it wasn't so a few

The cost of coding for string comparison is minimal (less than using
the 'ladder', but more than using language X's built-in classes) so
I'm happy to accept 'potentially a win' as good enough justification.
String comparison is a definite win where the id is generated in
canonical form, so I can't complain on those grounds.

Cheers,
Danny.

[1] http://www.ilrt.bris.ac.uk/discovery/chatlogs/foaf/2004-09-02.html#T11-25-11

-- 

http://dannyayers.com