[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] RE: Version identifier for XRD spec
FWIW, I think that schema version is independent of specification
version. the spec(s) can articulate which schema version is being
profiled.
=peterd
On Nov 24, 2008, at 2:18 AM, Drummond Reed 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
>
>
>
> ---------------------------------------------------------------------
> 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
>
Peter Davis: NeuStar, Inc.
Director & Distinguished Member of the Technical Staff
45980 Center Oak Plaza Sterling, VA 20166
[T] +1 571 434 5516 [E] peter.davis@neustar.biz [W] http://www.neustar.biz/
[X] xri://@neustar*pdavis [X] xri://=peterd
The information contained in this e-mail message is intended only for
the use of the recipient(s) named above and may contain confidential
and/or privileged information. If you are not the intended recipient
you have received this e-mail message in error and any review,
dissemination, distribution, or copying of this message is strictly
prohibited. If you have received this communication in error, please
notify us immediately and delete the original message.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]