Re: Fw: [cmis-comment] HREF values in Link Relation URIs, etc

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

[Al Brown said]

> How should we handle the CMIS specific link relations [...]
> Should a new style of a namespace document be created for each [...]

At Mary's request, I have formulated for Al Brown a proposal for
handling of the ten (eleven/twelve) URIs at the DNS+HTTP level
so that the URIs:

a) have some meaningful representation returned to an HTML agent
    when they are dereferenced, as we expect for HTTP scheme URIs

b) are handled as non-information resources (viz., distinguished
    in processing from typical 'information resources' [1]; thanks
    to the CMIS TC, a key feature enabling server-level support
    has already been accounted for by the decision to utilize the
    CMIS TC's /ns/ path element, which allows URI rewrites using
    existing machinery

Al's suggestion to use something like a "new style of a namespace
document" is precisely what I thought of as a solution with
I created a news story for the CMIS public review draft, and
realized (yikes!) that the link relation URIs don't resolve [2].

If we understand a namespace to be fundamentally a "space of
names", then it's not too difficult to see the analogy to XML
namespaces and namespace documents. The root URI for the
collection of CMIS link relation identifiers is:

  http://docs.oasis-open.org/ns/cmis/link/200908/

and each of the CMIS-specific link relations matching a
string identifier (URI) is a name in the hierarchical space
below /ns/cmis/link/200908/.

If a namespace document documents a namespace, then, by
analogy, a similar informative document (as an information
resource) can live at the end of the CMIS-specific link
relation URIs. Similar to the use of a single namespace
document to document several related URIs [3], a single
document could be used to document the key facts about
the CMIS-specific link relation URIs (associated
specification, spec owner(s), date, purpose, etc).

This analogy is (I think) consistent with an update I
made in August to the OASIS Naming Guidelines [4], clarifying
that use of the /ns/ path element seems like a reasonable
solution for "namespace related" URIs for collections of
named properties, functions, dialects, faults, actions,
and other message types as non-information resources.

Cheers,

- Robin Cover

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

=============== References:

[1] OASIS Naming Guidelines, non-information resources

http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNamingCommentaryV08.html#information-resources

[2] http://xml.coverpages.org/ni2009-10-30-a.html#Restful-AtomPub-section3
     see the enumertion at
     "In addition, several 'CMIS Specific Link Relations' are defined: [...]

[3] namespace document used to document collections of URIs

   I've seen several conventions in W3C specs for handling
   these kinds of special URIs, and some similar practices at
   OASIS have been used.  Here are the first examples I thought of:

** W3C property/relationship URIs

NS URI http://www.w3.org/2005/08/addressing
[WS-Addressing 1.0 Namespace]
with derivations
http://www.w3.org/2005/08/addressing/anonymous
[Web Services Addressing URI]
http://www.w3.org/2005/08/addressing/none
[Web Services Addressing URI]
http://www.w3.org/2005/08/addressing/unspecified
[Web Services Addressing URI]

**  OASIS specs with action URIs

NS URI http://docs.oasis-open.org/ws-rx/wsmc/200702/
with
http://docs.oasis-open.org/ws-rx/wsmc/200702/fault
http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection

[4] use of /ns/ path for non-information resources

"...named properties, functions, dialects, faults, actions, other
message types as non-information resources"
http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNamingV08.html#uri-collision



On Thu, 5 Nov 2009, Al Brown wrote:

>
> Mary,
>
> How should we handle the CMIS specific link relations.  They are not a
> namespace, XSD, or WSDL, but a string in URI form to convey meaning.  They
> are very specific to AtomPub and the new Link header for HTTP.
>
> For example, they are used like:
>
> <link rel="http://docs.oasis-open.org/ns/cmis/link/200901/allowableactions";
> href="foo" />
>
> That link element identifies a related resource (foo) of relation
> http://docs.oasis-open.org/ns/cmis/link/200901/allowableactions (e.g.,
> displays a document describing the allowed actions on that resource).
>
> Should a new style of a namespace document be created for each of the cmis
> specific link relations?  There are not 31 of them - more like 6 or so.
>
> Thanks,
> -Al
>
> Al Brown
> Office 714 327 3453
> Mobile 714 263 6441
> Email  albertcbrown@us.ibm.com
> CONFIDENTIAL NOTICE: The contents of this message, including any
> attachments, are confidential and are intended solely for the use of the
> person or entity to whom the message was addressed. If you are not the
> intended recipient of this message, please be advised that any
> dissemination, distribution, or use of the contents of this message is
> strictly prohibited. If you received this message in error, please notify
> the sender. Please also permanently delete all copies of the original
> message and any attached documentation.
> ----- Forwarded by Al Brown/Costa Mesa/IBM on 11/05/2009 03:07 PM -----
>
> From:	Robin Cover <robin@oasis-open.org>
> To:	CMIS Comment List <cmis-comment@lists.oasis-open.org>
> Cc:	Robin Cover <robin@oasis-open.org>
> Date:	11/05/2009 02:09 PM
> Subject:	[cmis-comment] HREF values in Link Relation URIs, etc
>
>
> In the CMIS Public Review draft (CD 04) at
> http://docs.oasis-open.org/cmis/CMIS/v1.0/cd04/cmis-spec-v1.0.html
>
> I noted several HTML links where the anchor HREF attribute values are
> different than the anchor element content, viz., the underlying
> HTML code in the HREF value appears to be incorrect, while the
> display text is apparently correct.
>
> Actually, this appears not to be a root HTML problem, but a defect in
> the editable source (.doc) from which HTML and PDF were apparently
> generated.
>
> Perhaps 30 or more of these, for example, in the section
> "CMIS Specific Link Relations":
>
> [a href="
> http://docs.oasis-open.org/ns/cmis/link/200901/allowableactions
> "]
> http://docs.oasis-open.org/ns/cmis/link/200908/allowableactions
>
> etc.
>
> test:
> $ grep -c 200901 cmis-spec-v1.0.html
> 31
>
> -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
>
> --
> This publicly archived list offers a means to provide input to the
> OASIS Content Management Interoperability Services (CMIS) TC.
>
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
>
> Subscribe: cmis-comment-subscribe@lists.oasis-open.org
> Unsubscribe: cmis-comment-unsubscribe@lists.oasis-open.org
> List help: cmis-comment-help@lists.oasis-open.org
> List archive: http://lists.oasis-open.org/archives/cmis-comment/
> Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cmis
>