RE: [tag] namespace issues still - One More Thing

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

I see that Mary McRae has already commented on this.  Here is what I was
writing while that happened [;<).

It is my understanding that we change the URLs for This Version at the same
time as we update the front matter for the CD that it has become.  That is,
the identification happens after approval.  This is important because we
don't want two documents having the same CDxx identification, even if the
differences are confined to production changes.

To be clear: A distinct working draft is identified in the ballot that
requests it being approved as CDxx.  We should never change identifying
material in a working draft in anticipation of its approval as a CD.  Once a
document is approved with a new status, a distinct copy that reflects that
status is produced.

 - Dennis

PS: I find it disconcerting to see new versions so quickly in response to
discussions and suggestions.  I think the churning could be cut down by
holding off until there is a quiet period.  Also, we never need more than
the editable versions for working drafts.  The additional forms can be
produced when an approved CD, CS, or OS is produced.

MORE THOUGHTS

CONCERNING "This version:" 

I don't think those URLs need to be accurate until producing the official
CDxx document.  I would make them obvious placeholders in working drafts
before CD01.  For working-draft revisions of a CDxx, I would either set them
back to placeholders or simply leave them alone until approval as CDxx+1.
It should be a standard checklist process to review and clean up all of the
URLs on the front page and also deal with whatever has to be done with the
page headers and footers when producing a copy of an approved document with
the new status that it has achieved.

FURTHER OBSERVATION

When a document-acceptance ballot passes, there are production changes made
to the balloted working draft so that it is identified as CDxx, all of the
URIs are correct for that CDxx, etc.  Then it is turned over, however that
is done, for appearance at the "This Version" URLs.  
   The currently applicable Namespace Document should be turned over at that
time too and it will go into the same directory.  Then OASIS will hook up
the Namespace URL to redirect to that version of the Namespace document.  
   I'm not sure what happens when there is already a CSxx or OASIS Standard
using that Namespace but we don't have that problem at this point.  So long
as the namespace is not being revised there is nothing to be concerned about
and the old Namespace Document is probably retained until the level of
document it refers to is supplanted.  
   I also believe that standalone Schema documents are supposed to link back
to the specific specification that they are normatively part of.  I notice,
for the standalone plaintext documents that are going out for public review
along with ODF 1.2 Committee Drafts, there are leading comments of this
kind:

<!--
    OASIS OpenDocument v1.2
	Committee Draft 04, 15 December 2009
    Relax-NG Schema

	Copyright © OASIS Open 2002-2009. All Rights Reserved.

[with the usual boilerplate notice information between here and ...]

 -->

And the file name, in the illustrated case, is 

    OpenDocument-schema-v1.2-cd04.rng

(Only one of the three parts of ODF 1.2 refer to this schema as normative,
although it is probably appropriate to put the Part number in the heading of
the schema file just to make sure we know which CDnn we are talking about.
I must turn in an issue about that.)

None of these were produced (nor any PDF or HTML) with cd04 in their text or
filenames until working document OpenDocument-v1.2-part1-cd03-rev07.odt was
approved as CD04.  At the ODF TC we do not attempt to make PDFs and HTMLs
for working drafts.  We just make editable versions and the schema drafts
are updated from time to time as needed.

-----Original Message-----
From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf
Of Stephen Green
http://lists.oasis-open.org/archives/tag/201001/msg00034.html
Sent: Thursday, January 07, 2010 11:13
To: TAG TC
Subject: Re: [tag] namespace issues still - One More Thing

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