[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tag] namespace issues still - One More Thing
Hi Stephen, Please don't add anything that indicates the document is at a level that it isn't at - that's why the TC Process allows for URLs, stage, approval date, etc. to be changed after passing. Thanks! Mary Mary P McRae Director, Standards Development Technical Committee Administrator OASIS: Advancing open standards for the information society email: mary.mcrae@oasis-open.org web: www.oasis-open.org twitter: @fiberartisan #oasisopen phone: 1.603.232.9090 Standards are like parachutes: they work best when they're open. On Jan 7, 2010, at 2:12 PM, Stephen Green wrote: > One more thing... > > I'll add the URLs to 'This Version:' in the titles > like > > http://docs.oasis-open.org/tag/taml/v1.0/cd01/testassertionmarkuplanguage-1.0-cd-01.html > http://docs.oasis-open.org/tag/taml/v1.0/cd01/testassertionmarkuplanguage-1.0-cd-01.odt > http://docs.oasis-open.org/tag/taml/v1.0/cd01/testassertionmarkuplanguage-1.0-cd-01.pdf > > to save having to add them after approval > (I'm not sure we're supposed to add them then) > which means I'll be sending a new model too. > > > Best regards > > Steve > --- > Stephen D Green > > > > > 2010/1/7 Stephen Green <stephen.green@documentengineeringservices.com>: >> Oh dear. I did say I'd wait and see if there was any more >> to add and looks like this is a valid extra feature worth >> including. Means a new couple of documents and a new >> schema then. I guess I can remove that semi-offending >> slash in the namespace at the same time - and put the >> beneficial slash at the end. Plus I'll update the date on the >> reference to the model spec in the markup spec to 2010. >> And I'll update the Namespace Document too. >> >> If I get no objections I'll update the documents as soon as >> possible. I'll make another iteration very soon (and any >> further changes requested after that will need yet another >> at the weekend, say, though I'm guessing we are good to >> go once this last change is made). >> >> Thanks Dennis. >> >> I always wondered what the benefit of the extra slash at >> the end of a namespace could be. >> >> Best regards >> >> Steve >> --- >> Stephen D Green >> >> >> >> >> 2010/1/7 Dennis E. Hamilton <dennis.hamilton@acm.org>: >>> Stephen, you need to decide quickly whether you want the namespace to be >>> usable with RDF for making what are called CURIEs. [Sorry, another one of >>> those things in my job jar for a long time and this exchange just kicked it >>> loose.) >>> >>> This is accomplished by ending the namespace URI with "/" or, if that >>> doesn't work with the redirector that OASIS will use for it, or -- my >>> recommendation -- put "#" as the last character of the namespace URI. (The >>> # is not seen by a redirector - fragment IDs are not passed to servers as >>> far as I can tell - but it is needed in the formal namespace URI because one >>> with and one without # are different according to the XML Namespace >>> specification. Likewise with and without a terminal "/".) >>> >>> It doesn't mean you have to do anything about RDF in TAML. This is simply a >>> valuable tweak so that people could make RDF about TAML-marked-up XML >>> documents, refer to TAML "concepts" in RDF, etc. This is a highly-valuable >>> thing to do. >>> >>> You would have to change the Namespace name in the current schema and also >>> anyplace the namespace URI is mentioned in the documents. >>> >>> (It also means that, if you chose to, you could add specific information on >>> the Namespace page at OASIS about the fragments (i.e., URIs) that are also >>> defined/reserved for use this way under the authority of the TAML >>> specification. I wouldn't worry about that in this round. What's nice is >>> it can be purely additive later and does not require Namespace revision if >>> the policy for TAML is to allow additions that preserve backward >>> compatibility.) >>> >>> -----Original Message----- >>> From: Mary McRae [mailto:mary.mcrae@oasis-open.org] >>> Sent: Thursday, January 07, 2010 07:24 >>> To: stephen.green@documentengineeringservices.com >>> Cc: TAG TC >>> Subject: Re: [tag] namespace issues still >>> >>> Hi Stephen, >>> >>> I believe that other TCs have done so, so you're in the clear. >>> >>> Mary >>> >>> >>> >>> On Jan 7, 2010, at 10:10 AM, Stephen Green wrote: >>> >>>> Thanks for helping us out Mary. >>>> >>>> The namespace we have at present is >>>> >>>> "http://docs.oasis-open.org/ns/tag/taml/201001"; >>>> >>>> If this would meet with your approval (I was thinking >>>> that the slash in "taml/201001" might be regarded >>>> as unconventional with respect to the ns guidelines) >>>> this would save me a whole lot of trouble by letting >>>> us ballot the existing specs and schema. >>>> >>>> Best regards >>>> >>>> Steve >>>> --- >>>> Stephen D Green >>>> >>>> >>>> >>>> >>>> 2010/1/7 Mary McRae <mary.mcrae@oasis-open.org>: >>>>> Hi Stephen, >>>>> >>>>> Here's a couple of factoids that might help. >>>>> >>>>> 1. The date string typically has nothing to do with the approval date in >>> practice. It seems that TCs decide at some point to include a number, pick >>> an arbitrary date, and stick with it. So don't worry that whatever date you >>> use has to match with the actual approval date at any particular stage of >>> the specification. >>>>> >>>>> 2. The TC is free to name the namespace. If you want to use taml that's >>> perfectly acceptable since 'tag' is already in the path. >>>>> >>>>> Regards, >>>>> >>>>> Mary >>>>> >>>>> >>>>> Mary P McRae >>>>> Director, Standards Development >>>>> Technical Committee Administrator >>>>> OASIS: Advancing open standards for the information society >>>>> email: mary.mcrae@oasis-open.org >>>>> web: www.oasis-open.org >>>>> twitter: @fiberartisan #oasisopen >>>>> phone: 1.603.232.9090 >>>>> >>>>> Standards are like parachutes: they work best when they're open. >>>>> >>>>> >>>>> >>>>> On Jan 7, 2010, at 6:37 AM, Stephen Green wrote: >>>>> >>>>>> Quoting >>> http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNaming.ht >>> ml#NamespaceDesign >>>>>> >>>>>> "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."; >>>>>> >>>>>> I note "unless an alternative URI is approved by the TC >>>>>> Administration" and by 'TC Administration' I take it it >>>>>> means the OASIS staff, rather than TAG TC. >>>>>> >>>>>> The pattern which for us would therefore be >>>>>> >>>>>> http://docs.oasis-open.org/ns/tag/<Versioned-NS-String> >>>>>> >>>>>> (where there are no slashes in '<Versioned-NS-String>' >>>>>> so that seems to make our existing namespace one >>>>>> requiring special TC Admin approval). >>>>>> >>>>>> This would mean we need something like >>>>>> >>>>>> http://docs.oasis-open.org/ns/tag/tag-20100129 >>>>>> >>>>>> The trouble is, to change the namespace I need to change >>>>>> the guidelines too (since they include the example markup). >>>>>> I don't know if we can assume the approval date will be >>>>>> 20100129 and it seems likely it could be sometime in Feb. >>>>>> On one hand the date needs to be able to reflect the precise >>>>>> committee draft (in case there is a further committee draft >>>>>> for version 1.0 requiring a change of namespace). On the other, >>>>>> I can't leave the namespace to the last minute after approval >>>>>> because the namespace needs to be changed in various >>>>>> places besides the titles (e.g. in the example in the guidelines >>>>>> and in the schema embedded in the markup spec). So my >>>>>> preference, which I think is within our scope of TC discretion, >>>>>> is to use a less precise date, just enough to pinpoint a >>>>>> uniques comittee draft. Because we might approve in Feb >>>>>> (could we time it to do so) more easily than limiting it to Jan >>>>>> I'd prefer Feb as a month of approval in case we need a >>>>>> second ballot or the ballot is delayed. >>>>>> >>>>>> i.e. >>>>>> http://docs.oasis-open.org/ns/tag/tag-201002 >>>>>> >>>>>> I'd kind of prefer to replace the second 'tag' with 'taml' but >>>>>> I'm not sure how much scope the TC has to do this so, unless >>>>>> assured by Admin http://docs.oasis-open.org/ns/tag/taml-201002 >>>>>> would be OK, I'll use >>>>>> >>>>>> http://docs.oasis-open.org/ns/tag/tag-201002 >>>>>> >>>>>> just to be on the safe side. >>>>>> >>>>>> It looks like I'll need to create a new set of documents. Sorry. >>>>>> >>>>>> Best regards >>>>>> >>>>>> Steve >>>>>> --- >>>>>> Stephen D Green >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> 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 >>>>>> >>>>> >>>>> >>> >>> >>> --------------------------------------------------------------------- >>> 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 >>> >>> >> > > --------------------------------------------------------------------- > 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]