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


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]