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



> Also, I note a trailing slash in the your example? Is it required?
> Recommended?

Slash is neither required nor recommended.  Some people prefer the
"slash" variant because it allows straightforward creation of derivative URIs
using QNames with simple concatenation (action URIs, etc)

Any of the three common types is allowed, per NG:

  "Any of the three common types of namespace names (URI references) are allowed:
   hash type, slash type, and simple (no-trailing-delimiter) type..."
http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNamingV08.html#threeTypesAllowed

The two candidates you supplied (http://docs.oasis-open.org/xri/ns/...) looked
OK to me.

-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, Drummond Reed wrote:

> Robin, thanks, I understand now that the older examples didn't include the
> explicit "/ns/" segment, but newer namespace URIs need to include it.
>
> So it sounds like what we want for XRD is:
>
> 	http://docs.oasis-open.org/xri/ns/xrd/1.0/
>
> ...or in the date form:
>
> 	http://docs.oasis-open.org/xri/ns/xrd/2008/12/
>
> Do I have these right?
>
> Also, I note a trailing slash in the your example? Is it required?
> Recommended?
>
> =Drummond
>
>> -----Original Message-----
>> From: Robin Cover [mailto:robin@oasis-open.org]
>> Sent: Monday, November 24, 2008 4:42 PM
>> To: Drummond Reed
>> Cc: 'Eran Hammer-Lahav'; 'Robin Cover'; 'Gabe Wachob'; 'Nat Sakimura';
>> mary.mcrae@oasis-open.org; 'OASIS XRI TC'; sakimura@spmd.nri.co.jp
>> Subject: RE: [xri] RE: Version identifier for XRD spec
>>
>> On Mon, 24 Nov 2008, Drummond Reed wrote:
>>
>>> I'm thinking that "/ns/" in the template corresponds to "/xscoor/" in
>> the
>>> instance example.
>> [...]
>>> I'm thinking what the template meant we could use was:
>>>
>>>       http://docs.oasis-open.org/xri/xrd/2008/12
>>
>> No.  Please see the text here:
>>
>> http://docs.oasis-
>> open.org/specGuidelines/namingGuidelines/resourceNamingV08.html#uri-NS-
>> root
>> http://docs.oasis-
>> open.org/specGuidelines/namingGuidelines/resourceNamingCommentaryV08.html#
>> NS-pathElement
>>
>> See the documentation for the new (Naming Guidelines -08)
>> pattern with the explicit /ns/ element, and example:
>>
>> http://docs.oasis-open.org/codelist/ns/genericode/1.0/
>>
>> Per:
>>
>> http://lists.oasis-open.org/archives/xri/200811/msg00125.html
>>
>> - Robin
>>
>> -------------------------------
>>
>>> Eran, our messages crossed in the mail. +1, but see inline for one
>>> clarification.
>>>
>>>> -----Original Message-----
>>>> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
>>>> Sent: Monday, November 24, 2008 3:49 PM
>>>> To: Drummond Reed; Robin Cover; Gabe Wachob
>>>> Cc: Nat Sakimura; mary.mcrae@oasis-open.org; OASIS XRI TC;
>>>> sakimura@spmd.nri.co.jp
>>>> 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>
>>>
>>> I'm thinking that "/ns/" in the template corresponds to "/xscoor/" in
>> the
>>> instance example.
>>>
>>>> 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
>>>
>>> I'm thinking what the template meant we could use was:
>>>
>>> 	http://docs.oasis-open.org/xri/xrd/2008/12
>>>
>>> But I'm sure Mary McRae can help us finalize the format - the key
>> concept is
>>> that we can use a date-based version identifier.
>>>
>>>> The actual date will be the month of the first draft.
>>>
>>> +1
>>>
>>> =Drummond
>>>
>>>> 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]