Re: [tag] Re: Namespace issue

[Stephen Green <stephen.green@documentengineeringservices.com>]

Thanks Dennis

Responses inline below.

Best regards

Steve
---
Stephen D Green




2010/1/6 Dennis E. Hamilton <dennis.hamilton@acm.org>:
> As well as I can tell, the statement in the template is a specimen, not a
> requirement.
>
> It also does not require a new namespace on a committee draft.  I assure you
> that is not the case.

Well the wording is quite definitive in that it defines what is technically
required for backwards compatibility in XML

Quote

"Under this policy, the following are examples of backwards compatible
changes that would not result in assignment of a new namespace URI:

    * addition of new global element, attribute, complexType and
simpleType definitions
    * addition of new operations within a WSDL portType or binding
(along with the corresponding schema, message and part definitions)
    * addition of new elements or attributes in locations covered by a
previously specified wildcard
    * modifications to the pattern facet of a type definition for
which the value-space of the previous definition remains valid or for
which the value-space of the preponderance of instance would remain
valid
    * modifications to the cardinality of elements for which the
value-space of possible instance documents conformant to the previous
revision of the schema would still be valid with regards to the
revised cardinality rule"


These are clearly those changes which are fairly incontrovertibly
minor version changes. Other changes are more controvertible such
as removal of optional elements before an wildcard, removal of optional
elements at the end of a sequence, modifications to enumerations, etc.
Incontrovertible major changes like removal of mandatory elements in
the middle of a sequence, addition of mandatory elements to a sequence,
etc do clearly require the assignment of a new namespace to a schema.
I don't think there would be much dispute about that and it does seem to
me that OASIS are, using this template, laying this down as a
requirement on TCs.

>
> It does require a new namespace document, but that is different.  The same
> namespace can be used.  Unless it isn't :).  The only difference in the new
> namespace document is that it needs to refer to a different committee draft,
> committee specification, or OASIS Standard as the latest definitive source.
> The namespace URI might never change.

If there is a breaking change (potentially any change not in the above
list but especially changes which are indisputably considered 'breaking')
then there has to be a new namespace if the change is to a committee
draft. That seems clear to me. The fact that the namespace has changed
also requires that an additional namespace document be created to
which the new namespace can resolve (effectively, virtually 'point'). The
namspace document refers to

"...a subsequent revision, published in conjunction with a Committee Draft..."

It also assures that the namespace will not change between drafts unless
it has to, "namespace URI will not change arbitrarily with each subsequent
revision...", between committee drafts. That's good.



>
> Good catch regarding the change to include /ns/.  However, I don't think you
> are constrained in any way on what happens after ns/tag/taml/ and you are
> certainly free to use a full date as you might prefer (e.g., 20100106 or
> 2010-01-06 or whatever we want to use as the placeholder for that namespace
> until such time as it might be revised at some future time.  You could even
> use a version number.

Well it seems to me that the pattern has to be one conforming to
one of the two general patterns in the naming guidelines:
http://docs.oasis-open.org/ns/<ShortName>/<Versioned-NS-String>
or
http://docs.oasis-open.org/ns/<ShortName>/<Versioned-NS-String>/
"unless an alternative URI is approved by the TC Administration".
So this does limit us, it seems to me (if 'TC Administration' means
OASIS Staff TC Administration), to one string we can adapt
<Versioned-NS-String> without any slashes and there is a pattern
for it which seems to be suggested, if not required
<ShortName>-<ApprovalDate>. The strategy does dictate something
like this in that there needs to be room to change the namespace for
the same version (major/minor), if need be, between committee drafts
if there are breaking changes (e.g. due to public review comments).
I'd prefer not to be limited to just <ShortName> with the first part and
be allowed to use just year and month for the approval date (to avoid
having to change the namespace once the approval date is fixed, as
it might mean changing the content of a spec and examples, etc). I
hope the pattern is not limited only to <ShortName>-<ApprovalDate>
for the <Versioned-NS-String>.

I'd like to avoid need for special dispensation from OASIS staff
if possible so we can keep as much as possible to our schedule
so if it is possible to fulfill the requirements completely I'd prefer it.


>
> There is more than could be usefully placed in the Namespace Document beyond
> what is illustrated in the template.  Unfortunately, I see the template
> being used without any further decoration beyond customization of what is
> already there.  Not a big worry at this point.  I just wanted to ease your
> concerns about the conditions under which a namespace has to be revised (as
> opposed to the namespace document, which always goes with a specific
> draft/edition of a specification).

Yes, but in our case I think we are trying to avoid taking
a lot of time on the Namespace Document and we have
minimal requirements anyway (only one schema and not
a huge chance of others namespaces besides TAML's
in the future). I understand that the committee process
is that OASIS staff assign a Namespace Document if there
is none created by the TC for a namespaced committee
draft, etc. Still, just as well to have the opprtunity that comes
from making our own - just that I'm trying to aim for keeping
to our best or second-best schedules (in case there are
complications, etc ...).


>
>  - Dennis
>
>
>
> -----Original Message-----
> From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf
> Of Stephen Green
> Sent: Wednesday, January 06, 2010 14:56
> To: TAG TC
> Subject: [tag] Re: Namespace issue
>
> Also, note the rules for what requires a new
> namespace once we agree a committee draft
> - the rules are hardwired into the namespace
> document template it seems.
>
> Best regards
>
> Steve
> ---
> Stephen D Green
>
>
>
>
> 2010/1/6 Stephen Green <stephen.green@documentengineeringservices.com>:
>> The OASIS namespace naming guidelines
>>
> http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNaming.ht
> ml#NamespaceDesign
>> seems to suggest our namespace needs to be changed to have the format
>> '.../ns/...' .
>>
>> I propose the namespace we use for (potential) committee draft 1 be
>> 'http://docs.oasis-open.org/ns/tag/taml/201001' to meet these
>> guidelines requirements.
>>
>>
>> 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
>
>