[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] RE: Version identifier for XRD spec
The rule for (HTTP Scheme) NS URI construction is here: http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNamingV08.html#uri-NS-root ------------------------------------------------------------------------------- HTTP scheme namespace URIs must be rooted at the "docs.oasis-open.org" Internet domain using one of the following two patterns with the /ns/ path element, unless an alternative URI is approved by the TC Administration: (1) http://docs.oasis-open.org/ns/<ShortName>/<Versioned-NS-String> OR (2) http://docs.oasis-open.org/<ShortName>/ns/<Versioned-NS-String>. ShortName is the approved short name for the TC or Member Section; Versioned-NS-String is a short string identifying a namespace using a versioning subcomponent. For example, given an imaginary TC short name 'ws-xx' and a versioned namespace string element 'WS-XX-20080115', a NS URI would be: http://docs.oasis-open.org/ns/ws-xx/WS-XX-20080115 OR http://docs.oasis-open.org/ws-xx/ns/WS-XX-20080115. ------------------------------------------------------------------------------ Note that the Versioned-NS-String can include a date, although other purely alphanumeric strings without (apparent) date elements could also be used. Version 08 of the Naming Guidelines intrroduced the /ns/ component (in one of two positions in the path), so earlier NS URIs [1] will not necessarily show the /ns/ component, now required. http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNamingCommentaryV08.html#NS-pathElement - Robin [1] earlier approved NS URIs http://docs.oasis-open.org/ws-sx/ws-trust/200512 http://docs.oasis-open.org/ws-tx/wscoor/2006/03 http://docs.oasis-open.org/wsbpel/2.0/varprop ---------- 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, Eran Hammer-Lahav wrote: > 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]