[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] RE: Version identifier for XRD spec
Robin, thanks for the guidance and links. I've suggested to Mary (who I
realize is gone this week) that we have a short telecon after she's back
with all the editors who will be working on the next round of specs from the
XRI TC, as several are new to OASIS specs and editing requirements.
=Drummond
> -----Original Message-----
> From: Robin Cover [mailto:robin@oasis-open.org]
> Sent: Monday, November 24, 2008 10:40 AM
> To: Gabe Wachob
> Cc: Eran Hammer-Lahav; 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
>
> Just a recommendation:
>
> I don't think it would be a mistake to keep one eye on details of the
> OASIS Naming Guidelines as the TC deliberates about such things
> as construction of a spec title, use of version/revision identifiers,
> namespace URI considerations, (required) use of both instance
> (version-specific) and generic (version-agnostic) URIs for schemas
> as well as prose specs, etc. And also, on the TC Process document.
>
> Examples:
>
> http://docs.oasis-
> open.org/specGuidelines/namingGuidelines/resourceNamingV08.html#NamespaceD
> esign
> (includes 'change policies for XML namespaces')
>
> http://docs.oasis-
> open.org/specGuidelines/namingGuidelines/metadata04.html#title
>
> http://docs.oasis-
> open.org/specGuidelines/namingGuidelines/metadata04.html#version
>
> http://docs.oasis-
> open.org/specGuidelines/namingGuidelines/metadata04.html#specURIs
>
> http://docs.oasis-
> open.org/specGuidelines/namingGuidelines/metadata04.html#declaredNamespace
> (namespace document, if you use HTTP scheme NS URI)
>
> http://docs.oasis-
> open.org/specGuidelines/namingGuidelines/metadata04.html#latestVersionURIs
> -schemas
> "Latest Version" URIs for Schemas, WSDLs, RDDLs, and Other Specification
> Components
>
> TC Prosess 2.18
> http://www.oasis-open.org/committees/process-2008-06-19.php#specQuality
>
> A specification may be composed of any number of files of
> different types, though any such multi-part specification
> must have a single specification name and version number.
> Irrespective of the number and status of the constituent
> parts, the specification as a whole must be approved by a
> single TC ballot. Any change made to a specification
> requires a new version or revision number...
>
> [NB Mary is out of the office for this week]
>
> -rcc
>
> Robin Cover
> OASIS, Director of Information Services
> Editor, Cover Pages and XML Daily Newslink
> Email: robin@oasis-open.org
> Staff bio: http://www.oasis-open.org/who/staff.php#cover
> Cover Pages: http://xml.coverpages.org/
> Newsletter: http://xml.coverpages.org/newsletterArchive.html
> Tel: +1 972-296-1783
>
>
> On Mon, 24 Nov 2008, 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]