[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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> 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 The actual date will be the month of the first draft. EHL 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]