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


Thanks, Robin, that's very helpful. I'm happy punting it to the editors to
take from here.

=Drummond 

> -----Original Message-----
> From: Robin Cover [mailto:robin@oasis-open.org]
> Sent: Monday, November 24, 2008 6:41 PM
> To: Drummond Reed
> Cc: 'Robin Cover'; 'Eran Hammer-Lahav'; '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
> 
> 
> > 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#threeTypes
> Allowed
> 
> 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]