[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] RE: Version identifier for XRD spec
The examples from Robinšs link directly point to:
http://docs.oasis-open.org/ws-tx/wscoor/2006/03
As a valid XML namespace. Perhaps missing the /ns/ component from the
current template:
http://docs.oasis-open.org/<ShortName>/ns/<Versioned-NS-String>
But either way, dates are definitely permitted within OASIS namespaces. I
therefore suggest this is a the resolution of this thread:
1. Spec name is XRD 1.0
2. Drop version attribute
3. XML namespace: http://docs.oasis-open.org/xri/ns/xrd/2008/12 (if still
allowed, otherwise) http://docs.oasis-open.org/xri/ns/xrd-200812
The actual date will be the month of the first draft.
EHL
On 11/24/08 3:36 PM, "Drummond Reed" <drummond.reed@cordance.net> wrote:
> 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]