[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]