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


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]