Re: [codelist] Dissenting argument on namespace URI

[Robin Cover <robin@oasis-open.org>]

Short answer: some legacy NS URIs do violate the rule; these cases were
grandfathered.

----------- Longer answer:

> missing something obvious?

No, you caught the obvious. In the 2005-2006 timeframe, several
activities in TAB and Staff (with two OASIS member reviews) tried
to address issues relating to namespace design.  At the time,
no direct support was available for adjustment of server config files
(e.g., for use of mod_rewrite directives), so we only had a crude
form of "redirect" to work with as we tried to manage the TCs'
namespace URIs and resources.

Over time, it became clearer to TAB members, Staff, and other
experts that overloading at the point of a directory/NS URI
would create problems -- given our commitment to transparently
display all directory contents.  In the interim, several TCs
had created content in directory URIs which collided with
namespace URIs, so we had to use clumsy, non-predictable
workarounds to provide views of the directory contents (index).

The result of this experience and many design discussions was to
create the rule you now see at "TCs should avoid creating
collision/confusion and semantic overloading..."

We grandfathered the instances on the file system of docs.oasis-open.org,
and will probably allow TCs that started out with the (now) deprecated
pattern to play out the remainder of their TC work in a consistent
way.  For new design work in TCs that are minting NS URIs, we intend
to require adherence to the rule "TCs should avoid creating
collision/confusion..."

Robin


On Tue, 17 Apr 2007, Anthony B. Coates (Miley Watts) wrote:

> Thanks, Robin.  Maybe you could help me in understanding the OASIS
> namespace URI guidelines
>
> http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNamingV07.html#NamespaceDesign
>
> a little better.  In particular the section
>
> ----
> TCs should avoid creating collision/confusion and semantic overloading at
> the point of a XML Namespace URI which could be mistaken for a regular
> directory URI, or vice versa; thus, for any Type 1 or Type 3 HTTP scheme
> namespace URI terminating in foo or foo/ (e.g.,
> http://http://docs.oasis-open.org/tcName/path/foo), no URIs should be
> created for resources matching "*" in
> http://http://docs.oasis-open.org/tcName/path/foo/*. IOW: we don't put any
> content in directory foo/.
> ----
>
> I understood this to mean that if the genericode 1.0 namespace URI is
>
> http://docs.oasis-open.org/codelist/genericode/1.0/
>
> that we can't have any documents whose access URI is of the form
>
> http://docs.oasis-open.org/codelist/genericode/1.0/*
>
> However, this is not consistent with the first two of the RDDL examples
> that you posted
>
> http://docs.oasis-open.org/ws-rx/wsmc/200702
> http://docs.oasis-open.org/ws-rx/wsrm/200702
>
> where there are documents in the directory of the namespace URI.  Am I
> missing something obvious?  Thanks,
>
> Cheers, Tony.
>
> On Mon, 16 Apr 2007 21:36:16 +0100, Robin Cover <robin@oasis-open.org>
> wrote:
>
> > Re:
> >
> >> As an aside, I had a look at the documents in
> >> "http://docs.oasis-open.org/";, and couldn't find any TCs that appear to
> >> be
> >> using RDDL, so I couldn't get any inspiration from what other TCs are
> >> doing.
> >
> > Good catch, Tony.  Thanks. We have an action item identifying the need
> > for
> > an OASIS registry of NS URIs, but it's not yet built.
> >
> > Meantime, some NS URIs that resolve to RDDLs (and indeed, this is
> > what we recommend):
> >
> > RDDLs:
> >
> > http://docs.oasis-open.org/ws-rx/wsmc/200702
> > http://docs.oasis-open.org/ws-rx/wsrm/200702
> > http://docs.oasis-open.org/ws-rx/wsrmp/200608
> > http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512
> > http://docs.oasis-open.org/ws-tx/wsat/2006/06
> > http://docs.oasis-open.org/ws-tx/wsba/2006/06
> > http://docs.oasis-open.org/ws-tx/wscoor/2006/03
> > http://docs.oasis-open.org/ws-tx/wscoor/2006/06
> > http://docs.oasis-open.org/wsbpel/2.0/plnktype
> > http://docs.oasis-open.org/wsbpel/2.0/process/abstract
> >
> > Non-OASIS:
> >
> > http://schemas.xmlsoap.org/ws/2004/04/sc
> > http://schemas.xmlsoap.org/ws/2004/08/eventing
> > http://schemas.xmlsoap.org/ws/2004/09/mex
> > http://schemas.xmlsoap.org/ws/2004/09/policy
> > http://schemas.xmlsoap.org/ws/2004/09/transfer
> > http://schemas.xmlsoap.org/ws/2005/02/rm
> > http://schemas.xmlsoap.org/ws/2005/04/ssi
> > http://www.opengis.net/gml
> > http://www.w3.org/2000/svg
> > http://www.w3.org/2005/08/addressing
> > http://www.w3.org/2005/08/ws-polling
> > http://www.w3.org/2005/SMIL21/
> >
> >
> > -rcc
> >
> > =====================================================================================
> >
> > On Mon, 16 Apr 2007, Anthony B. Coates (Miley Watts) wrote:
> >
> >> By my reading of the OASIS guidelines (which I didn't find completely
> >> clear), the recommended namespace URI for genericode would be
> >>
> >> http://docs.oasis-open.org/codelist/genericode/
> >>
> >> However, for practical reasons, I think we need to add the version
> >> number,
> >> so that the namespace URI becomes
> >>
> >> http://docs.oasis-open.org/codelist/genericode/1.0/
> >>
> >> Note that this URI does not contain "/ns/" as Ken's suggested URI
> >> does.  I
> >> don't see any place "/ns/" in the recommended format.  However, I think
> >> the RDDL document for genericode should be located at
> >>
> >> http://docs.oasis-open.org/codelist/genericode/
> >>
> >> and that all URIs of the form
> >>
> >> http://docs.oasis-open.org/codelist/genericode/M.N/
> >>
> >> should be redirected to a RDDL document at
> >>
> >> http://docs.oasis-open.org/codelist/genericode/
> >>
> >> which contains information about all versions of genericode.  However,
> >> that doesn't give us anywhere in the URL space to locate the Schemas.
> >>
> >> As an aside, I had a look at the documents in
> >> "http://docs.oasis-open.org/";, and couldn't find any TCs that appear to
> >> be
> >> using RDDL, so I couldn't get any inspiration from what other TCs are
> >> doing.
> >>
> >> So, in spite of what is suggested in the OASIS docs, I would actually
> >> prefer myself to follow Ken's suggestion of
> >>
> >> http://docs.oasis-open.org/codelist/ns/genericode/1.0/
> >>
> >> for the genericode 1.0 namespace URI, with this being redirected to a
> >> RDDL
> >> document at
> >>
> >> http://docs.oasis-open.org/codelist/ns/genericode/
> >>
> >> We could then have the Schemas at (I would suggest)
> >>
> >> http://docs.oasis-open.org/codelist/schemas/genericode/1.0/
> >>
> >> so that there is a consistent structure to the URLs.
> >>
> >> Comments?  Do we need to get OASIS to recommend something to us?
> >>
> >> Cheers, Tony.
> >>
> >> On Mon, 16 Apr 2007 16:42:28 +0100, G. Ken Holman
> >> <gkholman@CraneSoftwrights.com> wrote:
> >>
> >> > It has been brought to my attention that an OASIS policy that states
> >> > "HTTP scheme namespace URIs are to be preferred" is already in place:
> >> >
> >> >
> >> http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNamingV07.html#NamespaceDesign
> >> >
> >> > I do note that this policy does not allow other files in the
> >> directory,
> >> > so we cannot put the schema files in that directory as I had hoped.
> >> We
> >> > can perhaps create another directory with these files, say:
> >> >
> >> >    http://docs.oasis-open.org/codelist/genericode/1.0/
> >> >
> >> > I was unaware of these policy issues before writing my comments to Ray
> >> > ... would members please review the policy statements before
> >> tomorrow's
> >> > meeting?
> >> >
> >> > Thanks!
> >> >
> >> > . . . . . . . . . Ken
> >> >
> >> > At 2007-04-16 11:14 -0400, I wrote:
> >> >> Given that each committee can have its own repository, I'm suggesting
> >> >> we use something like:
> >> >>
> >> >>   http://docs.oasis-open.org/codelist/ns/genericode/1.0/
> >> >>
> >> >> as the namespace URI with an index.html at that directory in XHTML
> >> with
> >> >> RDDL statements, copies of the schema files in that directory as a
> >> >> central resource that anyone can point to, and any other information
> >> in
> >> >> support of the base specification.
> >> >>
> >> >> I understand we have polar opposite opinions on this with strong
> >> >> feelings behind both and, as a committee, we have to find a way to
> >> move
> >> >> forward.  The two suggestions on the table so far to consider are:
> >> >>
> >> >>   info:xmlns/oasis/codelist
> >> >>
> >> >> and
> >> >>
> >> >>   http://docs.oasis-open.org/codelist/ns/genericode/1.0/
> >> >>
> >> >> Would other members of the committee please give your opinions and
> >> >> other suggestions for consideration?
> >> >
> >> >
> >> > --
> >> > World-wide corporate, govt. & user group XML, XSL and UBL training
> >> > RSS feeds:     publicly-available developer resources and training
> >> > G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
> >> > Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
> >> > Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
> >> > Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
> >> > Legal business disclaimers:  http://www.CraneSoftwrights.com/legal
> >> >
> >>
> >>
> >>
> >> --
> >> Anthony B. Coates
> >> Senior Partner
> >> Miley Watts LLP
> >> Experts In Data
> >> +44 (79) 0543 9026
> >> Data standards participant: ISO 20022 (ISO 15022 XML), ISO 19312,
> >> UN/CEFACT TMG, MDDL, FpML, UBL.
> >> http://www.mileywatts.com/
> >>
>
>
>
> --
> Anthony B. Coates
> Senior Partner
> Miley Watts LLP
> Experts In Data
> +44 (79) 0543 9026
> Data standards participant: ISO 20022 (ISO 15022 XML), ISO 19312,
> UN/CEFACT TMG, MDDL, FpML, UBL.
> http://www.mileywatts.com/
>