OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri] TAG discussion of versioning in URIs


Answering Gabe's questions about XRI-cross-references-as-version-tags:

1) As far as human usability, I've never considered versioning syntax to
fall under the "human optimization" requirement of XRIs. While I can
concieve of use cases where a human might actually type or select a
version date or number, I've always thought it's primarily for machine
use (where I believe it's tremendously useful). I expect it will mostly
be added by UIs and software processing XRIs, not by end-users.

2) I agree with Gabe and Peter that "providing a syntax for versions
doesn't import the complexity inherent in using and interpreting those
versions". If a resolver or XRI server doesn't support versioning and
only supports current-version-identifiers, it would simply ignore the
version syntax portion. Or if it only supports certain basic types of
version syntax, like datetime and numeric, then it would ignore other
syntaxes. The nice part is that the resource generating the versioning
syntax in an XRI is ultimately likely to be the resource responsible for
interpreting it. So all we need to do is provide the overall spot in the
syntax.

3) I generally agree with Peter about the cross-reference form of
versioning, i.e. that "the version string could be an XRI itself,
resolving to the specification of the versioning notation employed for
this instance of the resource, as well as the version identifier
(whatever that is is determined by the version specification itself)."
My only addition would be to suggest that the most common version
formats (datetime, numberpath, textpath) should be prefixed for
compactness. Any other custom version format should be a full XRI for
full extensibility.

=Drummond


-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com]
Sent: Tuesday, April 22, 2003 12:25 PM
To: 'xri@lists.oasis-open.org'
Subject: RE: [xri] TAG discussion of versioning in URIs

I really like the XRI-cross-reference-as-version-tag, but I think it
conflicts with the human usability aspect (drummond? dave mcalpin? I
think this is more important a concern to them).

I tend to agree with you that providing a syntax for versions doesn't
import the complexity inherent in using and interpreting those versions.

Does anybody else have opinions on the threshold question of whether or
not to support version syntax, in general?

        -Gabe

> -----Original Message-----
> From: Peter C Davis [mailto:peter.davis@neustar.biz]
> Sent: Tuesday, April 22, 2003 7:49 AM
> To: 'xri@lists.oasis-open.org'
> Subject: Re: [xri] TAG discussion of versioning in URIs
>
>
> Wachob, Gabe wrote:
>
> >I'm not sure there's been a lot of discussion (relative to a
> lot of other topics) about versioning, but there seems to be
> a consensus among those on the TAG that versioning of URIs is
> a nonstarter. I'm not sure that they've really explained the
> issue with versioning besides to say "its complicated". I
> happen to agree that the interpretation of versions can be
> complicated, but I am not sure if we are going to deal with
> that complication here or whether it becomes an application
> issue (for applications using versioned XRIs).
> >
> >
> >
> While i agree with TBL that versioning is complicated, it is only so
> when one attempts to apply "meaning" to the version
> identifier.  I think
> this IS an application/implimentation issue, best left out of
> scope for
> XRI.  Simply providing a means to express versions within the
> structure
> should be our aim, not detailed normative text attempting to
> sovle the
> problem.
>
> In fact, now that i think about it, the version string could
> be an XRI
> itself, resolving to the specification of the versioning notation
> employed for this instance of the resource, as well as the version
> identifier (whatever that is is determined by the version
> sepcification
> itself). Continuing the "host version" thread:
>
>     host[@urn:dns:versionspec:serial:2002030415].foo.biz/this/resource
>
> (@ was arbitrary on my part.... versioning specifications may
> have IPR
> attached to them??).
> So dereferencing urn:dns:versionspec:serial provides the semantics of
> "things to the right"...
>
> --- peterd
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]