[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] RE: Version identifier for XRD spec
Robin, thanks, I understand now that the older examples didn't include the explicit "/ns/" segment, but newer namespace URIs need to include it. So it sounds like what we want for XRD is: http://docs.oasis-open.org/xri/ns/xrd/1.0/ ...or in the date form: http://docs.oasis-open.org/xri/ns/xrd/2008/12/ Do I have these right? Also, I note a trailing slash in the your example? Is it required? Recommended? =Drummond > -----Original Message----- > From: Robin Cover [mailto:robin@oasis-open.org] > Sent: Monday, November 24, 2008 4:42 PM > To: Drummond Reed > Cc: 'Eran Hammer-Lahav'; 'Robin Cover'; 'Gabe Wachob'; 'Nat Sakimura'; > mary.mcrae@oasis-open.org; 'OASIS XRI TC'; sakimura@spmd.nri.co.jp > 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]