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