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] RE: Version identifier for XRD spec


FYI this is the OASIS doc on using URI/URN for namespaces.  
http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNaming.html

It looks like we need to put it in the form:
http://docs.oasis-open.org/<ShortName>/ns/<Versioned-NS-String>
or
http://docs.oasis-open.org/xri/ns/xrd-2009-01-01

if we want to use a date.

John B.
On 24-Nov-08, at 10:17 AM, Gabe Wachob wrote:

I'd be happy with calling it XRD 1.0 if we use a dated namespace so people don't have *any* confusion about the fact that this is the "most current" spec relative to XRI... 

Its also a sort of emerging best practice for namespaces from the W3C, afaict. 

And of course, I'm happy with an HTTP namespace ;)

I'm happy with dropping version - that was there mostly to allow backwards compatibility - the idea being that a future interpreter could pick up an older XML document and understand what it was looking at. This would leave us as spec writers free to add new elements in a "backwards compatible" manner, while allowing the documen to give hints to "up to date" implementations what level the spec was at. The idea was that you would be able to rev the schema much slower than the spec interpreting it. 

     -Gabe

On Nov 24, 2008, at 9:11 AM, Eran Hammer-Lahav wrote:

My vote is to:

  • Name the spec XRD 1.0
  • Drop the ‘version’ attribute
  • Drop the proposal to have multiple ‘profiles’ (i.e. XRDS-Simple)
  • Use an HTTP namespace under the OASIS domain with version 1.0. If people find this confusing, I would be ok with a dated namespace. As a last resort, I would support using a version 3.0 namespace with an explanation why the spec itself is version 1.0.

Here is why:


I think the real question here is what to do with the ‘version’ attribute. In many ways, it is very similar to the ‘profile’ attribute proposed earlier to support the XRDS-Simple use case. I am –1 on both and here is why. My understanding of the ‘version’ attribute is that it refers only to the resolver workflow, not to the schema which is independently versioned via an XML namespace.

I cannot think of use cases where the schema does not change at all, but the meaning of the document does. The most likely scenario to happen is adding elements via XML namespace import, and in that case, the resolver will need to take those new additions into account (as they may change the meaning of the document). I believe that the schema itself is more than just a format but also tightly linked to its meaning. If we want to change the meaning but not the schema, we should still change the XML namespace. Either way, existing parsers will need to change so why does it matter what breaks them (different version of different namespace).

In addition, I have changed my views on the ‘profile’ attribute. I think at this point the only element which might be considered ‘advance’ is <Ref> and it is an important requirement for any delegation of metadata. The only other issue raised by developers was the ‘priority’ attribute but again, it is too important to remove.

If we remove these two attributes, we are left with a single unified schema which will get a new namespace. Since this new namespace will be an HTTP URI, I do not think it matters if it is version 1.0 or dated. It will be sufficiently different form the XRI namespace (which more people didn’t understand) and from the version attribute value. Because of that I lean more towards a version 1.0 in the namespace than a date, but will take a date over version 3.0.

The spec itself should be XRD 1.0 either way, not matter what namespace we end up using (and assuming we are dropping the ‘version’ attribute). It is better to version it 1.0 and put a comment why the namespace has 3.0 in it, than make everything 3.0...

EHL


On 11/23/08 11:18 PM, "Drummond Reed" <drummond.reed@cordance.net> wrote:

Nat, RE your [Q1], I don't think OASIS mandates how schemas are versioned.
That's up to individual TCs (I'm trusting Mary or Robin will correct me if
I'm wrong.]

RE your [Q2], I think that it is also up to us when we make a version
change. Changing the schema would seem to be one of the conditions under
which we would definitely make a version change, but it does seem like other
spec changes could also trigger a version change (for example, as you
mentioned, verification rules).

Suggestion: since much of this seems to hinge around whether the XRD schema
retains a version attribute, why don't selector see if we can decide that
first.

1) Who has strong feelings one way or another about whether the XRD schema
should have a version attribute?

2) If so, should the use of the version attribute be required?

3) If there is a version attribute, who has strong feeling about it being
numeric (as it currently is in XRI Resolution 2.0)? Or a date value?

=Drummond

> -----Original Message-----
> From: Nat Sakimura [mailto:n-sakimura@nri.co.jp]
> Sent: Sunday, November 23, 2008 6:11 AM
> To: mary.mcrae@oasis-open.org; OASIS XRI TC
> Cc: Gabe Wachob; Drummond Reed; Eran Hammer-Lahav; sakimura@spmd.nri.co.jp
> Subject: Re: [xri] RE: Version identifier for XRD spec
>
> So, to sum it up, there has been several information points/resonings
> available around versions:
>
> (1) Since it is a new spec, it shoud start from 1.0. Otherwise people
> start looking for 1.0.
> (2) Since there is <XRD version="2.0" xmlns="xri://$xrd*($v*2.0)"> in
> XRDS right now.
>       using 1.0 may confuse people. Perhaps we should use 3.0.
> (3) However, if version attribute goes away, this is of less concern.
>       Version of the schema can be represented in xmlns, and it will be
> a new
>       http based version string possibly starting from 1.0 or dates in
> W3C style.
>       Besides, schema version and spec version can be separate.
> (4) OASIS rule mandates the specs to be versioned numerically.
>
> I have a couple of questions at this point.
>
> [Q1] Is the OASIS versioning rule on the spec also applicable to the
> schema contained in the spec?
> [Q2] Is there a case where we want to preserve "version" attribute
> separate from the schema version?
>    e.g., when verification rule is changed etc., should it always
> require the schema version change as well?
>
> If the answer to [Q1] is no, then we can use date based name space in
> <XRD ... > and cause
> less confusion even if we adopt XRD 1.0. If the answer is "Yes", then I
> would be more inclined to "3.0".
>
> For [Q2], I am yet to come up with a case. If any of you could think of
> it, please let me know.
>
> =nat
>
>
>
>
> Gabe Wachob wrote:
> > Lets call it XRD 7!
> >
> >     -Gabe
> >
> > On Fri, Nov 21, 2008 at 11:11 PM, Drummond Reed
> > <drummond.reed@cordance.net <mailto:drummond.reed@cordance.net>> wrote:
> >
> >     Mary McRae, our TC admin, clarified that OASIS specs must use a
> >     numeric
> >     version identifier (see thread below).
> >
> >     So, mates, now we really do have to decide between "XRD 1.0" and
> >     "XRD 3.0".
> >
> >     A suggestion: if, as we discussed on Thursday's call, the new XRD
> >     spec will
> >     no longer have a "ver" attribute on the XRD element, then the
> >     issue of the
> >     previous version attribute value being "2.0" (as specified in XRI
> >     Resolution
> >     2.0) will go away. In that case I think it makes sense to call the
> >     spec "XRD
> >     1.0" because as Eran pointed out, there's never been a spec from
> >     the TC
> >     called "XRD" before.
> >
> >     OTOH, if the decision is that the ver attribute on XRD element
> >     should stay,
> >     then I think it makes sense to call the spec "XRD 3.0" because it
> >     really is
> >     the next version of XRD. We can always put a note in the
> >     frontmatter telling
> >     readers not to look for an "XRD 2.0" or "XRD 1.0" spec, but
> >     instead to look
> >     at "XRI Resolution 2.0" and "XRI 1.0" for the predecessor
> >     specifications.
> >
> >     All things being equal (which they never are ;-), I favor planning
> for
> >     future growth and extensibility, which means I favor keeping the
> >     versioning
> >     attribute, which tips me ever so slightly towards "XRD 3.0". (Which
> is
> >     ironic because I prefer the spec name "XRD 1.0" because it's a new
> >     spec.)
> >
> >     I don't think the issue is worth taking a bunch of list bandwidth
> >     to figure
> >     out, so I'd recommend that:
> >
> >     a) Anyone else on the list with strong feelings either way, please
> >     post your
> >     thoughts by Monday.
> >
> >     b) Eran and Nat as the editors discuss it and make a recommendation.
> >
> >     =Drummond
> >
> >
> >     > -----Original Message-----
> >     > From: Mary McRae [mailto:marypmcrae@gmail.com
> >     <mailto:marypmcrae@gmail.com>] On Behalf Of Mary McRae
> >     > Sent: Friday, November 21, 2008 5:23 AM
> >     > To: 'Drummond Reed'
> >     > Subject: RE: Version identifier for XRD spec
> >     >
> >     > You found the right (and required) answer ;-)
> >     >
> >     > Mary
> >     >
> >     > > -----Original Message-----
> >     > > From: Drummond Reed [mailto:drummond.reed@cordance.net
> >     <mailto:drummond.reed@cordance.net>]
> >     > > Sent: Friday, November 21, 2008 1:22 AM
> >     > > To: 'OASIS XRI TC'; mary.mcrae@oasis-open.org
> >     <mailto:mary.mcrae@oasis-open.org>
> >     > > Subject: Version identifier for XRD spec
> >     > >
> >     > > Mary,
> >     > >
> >     > > From today's XRI TC call I had an action item to send you and
> >     the TC
> >     > > list an
> >     > > email asking about OASIS spec naming guidelines. Based on the
> >     helpful
> >     > > info
> >     > > about spec packaging you gave us two weeks ago, the TC is
> >     currently
> >     > > planning
> >     > > two new specs, both of which we intend to take to OASIS
> >     Standard level:
> >     > > XRI
> >     > > 3.0 and XRD xxx (xxx = version identifier TBD).
> >     > >
> >     > > XRI 3.0 will consist of four parts (1: Syntax, 2: Resolution,
> >     3: http:
> >     > > and
> >     > > https: Bindings, and 4: info: Binding). XRD will probably be a
> >     single
> >     > > spec,
> >     > > though it might be two parts.
> >     > >
> >     > > Now, the question is about versioning on the XRD spec. This is
> >     a new
> >     > > spec
> >     > > that represents splitting off a significant portion of the
> >     content of
> >     > > the
> >     > > XRI Resolution 2.0 spec into a new spec that defines a generic
> >     metadata
> >     > > discovery format and protocol which the new XRI 3.0 Part 2:
> >     Resolution
> >     > > spec
> >     > > will then profile (as will other specs, e.g. SAML, OpenID,
> >     OAuth, etc.
> >     > > who
> >     > > want to use interoperable discovery).
> >     > >
> >     > > Our first question is: does an OASIS spec need to use a
> >     numeric version
> >     > > identifier? In researching this tonight, I believe the answer
> >     is at:
> >     > >
> >     > >
> >     > > http://docs.oasis-
> >     > > open.org/specGuidelines/namingGuidelines/metadata.html#ver
> >     <http://open.org/specGuidelines/namingGuidelines/metadata.html#ver>
> >     > > sion
> >     > >
> >     > > ...which states:
> >     > >
> >     > > *******************
> >     > > A specification Version is represented textually by a numeric
> >     string
> >     > > composed of digits [0-9] and period (".") corresponding to any
> >     of the
> >     > > following lexical models provided below (as examples), as may be
> >     > > relevant to
> >     > > the TC's work activity and preference for major/minor version
> >     notation.
> >     > > Formally, using parenthesis to indicate optionality and "#" to
> >     > > represent a
> >     > > digit, the allowable pattern is: #(#).#(#)(.#(#)). Use of any
> >     other
> >     > > pattern
> >     > > for version number must be negotiated with the TC
> Administration.
> >     > >
> >     > > Examples:
> >     > >
> >     > > 1.0      #.#
> >     > > 1.01     #.##
> >     > > 1.2.1    #.#.#
> >     > > 10.1     ##.#
> >     > > ********************
> >     > >
> >     > > If so, that answers the question, and we just need to decide
> what
> >     > > version
> >     > > number to give it (in short: one rationale is to call it 1.0
> >     because it
> >     > > is a
> >     > > new spec; another is to call it 3.0 because it derives from two
> >     > > generations
> >     > > of XRDS before it -- but that's our issue to figure out).
> >     > >
> >     > > However, if we do have any flexibility, we want to at least
> >     ask you
> >     > > about
> >     > > using a year/date identifier instead of a version number.
> >     > >
> >     > > Thanks in advance. (BTW, I'm thinking of setting up a call in
> >     early
> >     > > December
> >     > > between you and the editors of these new specs to a general
> >     Q&A about
> >     > > all
> >     > > things involved with the mechanics of an OASIS spec. Sound
> >     like a good
> >     > > idea?)
> >     > >
> >     > > =Drummond
> >
> >
> >
> >     --------------------------------------------------------------------
> -
> >     To unsubscribe from this mail list, you must leave the OASIS TC that
> >     generates this mail.  Follow this link to all your TCs in OASIS at:
> >     https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> >
> >
> > --
> > Gabe Wachob / gwachob@wachob.com <mailto:gwachob@wachob.com> \
> > http://blog.wachob.com
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php







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