[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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#NamespaceDesign
(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]