Re: [xri] RE: Version identifier for XRD spec

[Nat Sakimura <n-sakimura@nri.co.jp>]

+1 for XRD 1.0 and date NS.

Drummond Reed wrote:
>
> Given that Gabe was the initial champion of the version attribute for 
> XRD, if he’s satisfied, I’m satisfied. I think Eran’s argument about 
> using the XML namespace for the new XRD schema as the version 
> identifier is a strong one.
>
> So on this first issue, I propose we go for the close:
>
> The new spec will be called “XRD 1.0” unless anyone explicitly objects 
> by responding to this thread.
>
> Given that it’s Thanksgiving week in the U.S., I suppose we ought to 
> consider this provisional until next Monday.
>
> **************
>
> On the second issue of the XML namespace identifier, I personally am 
> fine with using either a numeric or a date identifier, (although I 
> can’t resist pointing out that the reason we used an XRI the first 
> time around was to provide an identifier for which versioning 
> semantics are actually _/defined in a machine-understandable format/_, 
> which I would favor over any non-machine-understandable option). That 
> said, I’m happy to leave it to the editorial team to make a 
> recommendation.
>
> **************
>
> A third issue we’ve run into before is one I’d like to nip in the bud. 
> “XRD 1.0” is very short and concise and also the way the spec will 
> typically be referred to. However sometimes OASIS requires TCs to 
> spell acronyms out. For example, the formal name of the SAML 2.0 Core 
> spec 
> (http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf) is:
>
> Assertions and Protocols for the OASIS Security Assertion Markup 
> Language (SAML) V2.0
>
> Because “XRD” is not the name of the TC, I believe that we as TC can 
> declare that the acronym IS the name of the specification. In that 
> case, since OASIS does require the use of a capital “V” before the 
> spec version number, the formal name of this specification would be:
>
> XRD V1.0
>
> …and not…
>
> Extensible Resource Descriptor (XRD) V1.0
>
> Anyone who does NOT want to use the shorter option – “XRD V1.0” – as 
> the formal name of the spec, please reply back to this thread, or else 
> we’ll assume that’s our title (unless Mary McRae has any other issues 
> once she’s back from vacation).
>
> =Drummond
>
> ------------------------------------------------------------------------
>
> *From:* Gabe Wachob [mailto:gwachob@gmail.com] *On Behalf Of *Gabe Wachob
> *Sent:* Monday, November 24, 2008 10:17 AM
> *To:* Eran Hammer-Lahav
> *Cc:* Drummond Reed; Nat Sakimura; mary.mcrae@oasis-open.org; OASIS 
> XRI TC; sakimura@spmd.nri.co.jp
> *Subject:* Re: [xri] RE: Version identifier for XRD spec
>
> 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> 
> <mailto:drummond.reed@cordance.net%3e>> 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> <mailto:marypmcrae@gmail.com%3e>] 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> 
> <mailto:drummond.reed@cordance.net%3e>]
> > > > > 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
>
>