RE: [xri-editors] XRIs and canonical form

["Wachob, Gabe" <gwachob@visa.com>]

While this is true (about canonicalization of cross references), I think its perfectly reasonable to talk about canonicalization of those parts we have control over (ie XRI-defined syntax).  Perhaps "canonical" is too strong a word.

I suspect that the vast majority of XRIs will not contains cross references containing other URI schemes. And in those cases where they do, maybe we'll have to live with the fact that there is not one canonical form. 

Maybe we call it "XRI canonicalized URI form" to suggest that its only canonicalized as far as XRI syntax goes..

	-Gabe


> -----Original Message-----
> From: Dave McAlpin [mailto:dave.mcalpin@epokinc.com]
> Sent: Tuesday, November 11, 2003 11:06 AM
> To: 'Wachob, Gabe'; xri-editors@lists.oasis-open.org
> Subject: RE: [xri-editors] XRIs and canonical form
> 
> 
> It's interesting that neither 2396 nor 2616 defined a canonical form.
> 2396bis defines some "good practices" for making URIs "reasonably
> canonical", but they don't attempt anything normative. The 
> following post by
> Larry Masinter is instructive.
> 
> > In general, URLs do _not_ have a canonical form. However, HTTP
> > defines some equivalences for URLs (e.g., that http://host is 
> > equivalent to http://host/, and by using the generic
> > syntax for host names, the host part is case insensitive).
> > 
> > Some particular HTTP servers MAY define other equivalences,
> > e.g., that http://host/dir is equivalent to http://host/dir/
> > and to http://host/dir/index.html.
> > 
> 
> Given that URIs don't have a normative canonical form, it's 
> hard to see how
> we can define a canonical form for XRIs that contain cross-references.
> 
> Dave
> 
> > -----Original Message-----
> > From: Wachob, Gabe [mailto:gwachob@visa.com]
> > Sent: Tuesday, November 11, 2003 10:58 AM
> > To: 'Dave McAlpin'; xri-editors@lists.oasis-open.org
> > Subject: RE: [xri-editors] XRIs and canonical form
> > 
> > I think canonical form is sort an arbitrary, but well 
> understood "state"
> > of an identifier.
> > 
> > When an identifier is in canonical form, it should be 
> possible to compare
> > it with another identifier in canonical form and the 
> process of comparing
> > the two character-by-character (or in the case of 
> canonicalized URIs, byte
> > for byte) is exactly the process of applying the built-in 
> equivalence
> > rules in the XRI spec.
> > 
> > Does this make sense? I mentioned the leading-. issue, the 
> $! and ! cross
> > references. One other thing that would be useful to describe for
> > canonicalization is the uppercasing of %HH (hex digit)..
> > 
> > If we define resolution to operate only on canonicalized forms of
> > identifiers, it potentially makes the deployment of XRI local access
> > servers MUCH simpler as they don't have to apply any of the 
> "built-in"
> > equivalence rules themselves. They just have to make sure that they
> > resolve the one canonical form...
> > 
> > 	-Gabe
> > 
> > > -----Original Message-----
> > > From: Dave McAlpin [mailto:dave.mcalpin@epokinc.com]
> > > Sent: Tuesday, November 11, 2003 10:50 AM
> > > To: xri-editors@lists.oasis-open.org
> > > Subject: [xri-editors] XRIs and canonical form
> > >
> > >
> > > I've been asked to draft text specifying a "canonical form"
> > > for XRIs. I
> > > wanted to start by understanding what canonical form 
> meant for URIs in
> > > general, and in searching the web I came across the following
> > > exchange. The
> > > initial question is from Terence Spielman of Visa, followed
> > > by Gabe's and my
> > > responses. Just interesting that we've considered this
> > > question before.
> > >
> > > Dave
> > >
> > > >>>In addition, aside from unresolvable references, is it possible
> > > >>> to canonicalize XRIs?  This is a highly desireable feature
> > > >>> (for equivalence, at a minimum).
> > >
> > > >>We talked quite a bit about this. The decision was made to
> > > be silent on
> > > >>canonicalization because equivalence is actually
> > > unambigious given the
> > > >>rules stated. Now, that doesn't mean that its at all obvious.
> > > >>
> > > >>I do think giving names to the escaped vs. unescpaed forms
> > > of XRI, at
> > > >>least, would be useful.  Canonicalization would then just
> > > be transforming
> > > >>an identifier into one of those forms. We didn't want to
> > > mandate a single
> > > >>canonical form because different environments would need
> > > XRIs in different
> > > >>levels of escaping and it would be unfortunate to 
> require a specific
> > > >>canonicalization form that would require otherwise-unneeded
> > > transformation.
> > > >>
> > > >>Again, Dave McAlpin probably has better input on this.
> > >
> > > >A canonical representation might be useful for comparison,
> > > but it would
> > > >involve a formal definition of things like "minimally
> > > escaped", which would
> > > >be fairly difficult to nail down. It would also depend on
> > > the existence of
> > > >a canonical form for URIs used as cross-references. In other
> > > words, an XRI
> > > >wouldn't have a canonical form if it contained
> > > cross-references that didn't
> > > >define a canonical form.
> > > >
> > > >Note that equivalence rules are generally problematic. The
> > > IRI proposal,
> > > >for example, completely dodges the question of equivalence
> > > when it says,
> > > >"There is no general rule or procedure to decide whether two
> > > arbitrary IRIs
> > > >are equivalent or not... Each specification or application
> > > that uses IRIs
> > > >has to decide on the appropriate criterion for IRI
> > > equivalence." 2396bis
> > > >notes that even terms like "different" and "equivalent" are
> > > fuzzy in the
> > > >general spec and ultimately application dependent.
> > >
> > >
> > >
> > >
> > >
> > > To unsubscribe from this mailing list (and be removed from
> > > the roster of the OASIS TC), go to
> > > http://www.oasis-open.org/apps/org/workgroup/xri-editors/membe
> > rs/leave_workgroup.php.
> > 
> > To unsubscribe from this mailing list (and be removed from 
> the roster of
> > the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/xri-
> > editors/members/leave_workgroup.php.
> 
> 
> 
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/xri-editors/membe
rs/leave_workgroup.php.