OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


The rule for (HTTP Scheme) NS URI construction is here:

http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNamingV08.html#uri-NS-root

-------------------------------------------------------------------------------

HTTP scheme namespace URIs must be rooted at the "docs.oasis-open.org"
Internet domain using one of the following two patterns with the
/ns/ path element, unless an alternative URI is approved by the TC
Administration: (1)
http://docs.oasis-open.org/ns/<ShortName>/<Versioned-NS-String> OR
(2) http://docs.oasis-open.org/<ShortName>/ns/<Versioned-NS-String>.
ShortName is the approved short name for the TC or Member Section;
Versioned-NS-String is a short string identifying a namespace using
a versioning subcomponent. For example, given an imaginary TC short
name 'ws-xx' and a versioned namespace string element 'WS-XX-20080115',
a NS URI would be: http://docs.oasis-open.org/ns/ws-xx/WS-XX-20080115 OR 
http://docs.oasis-open.org/ws-xx/ns/WS-XX-20080115.

------------------------------------------------------------------------------

Note that the Versioned-NS-String can include a date, although other
purely alphanumeric strings without (apparent) date elements could also
be used.

Version 08 of the Naming Guidelines intrroduced the /ns/ component (in one
of two positions in the path), so earlier NS URIs [1] will not necessarily
show the /ns/ component, now required.

http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNamingCommentaryV08.html#NS-pathElement

- Robin

[1] earlier approved NS URIs

http://docs.oasis-open.org/ws-sx/ws-trust/200512
http://docs.oasis-open.org/ws-tx/wscoor/2006/03
http://docs.oasis-open.org/wsbpel/2.0/varprop

----------

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, Eran Hammer-Lahav wrote:

> 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]