[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Fw: [cmis-comment] HREF values in Link Relation URIs, etc
[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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]