OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-calendar message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [ws-calendar] construction pattern for property identifiers in the REST spec

Toby,

Thanks for taking the action item to fix the property identifiers in the
next WD for ws-calendar-rest [4]

As I was closing windows earlier today, I composed a note for the
TC Admin team to clarify rationale our historic practice, per the
Naming Directives document, on construction of these identifiers.
I think the writeup may be useful more broadly, so I'm posting it to
your WS-Calendar TC and will (thereby) get a re-usable reference:

Cheers,

- Robin

================================================

If an OASIS TC's Work Product provides identifiers (strings)
using [OASIS URNs or] URIs that begin with http://,
then the identifiers need to conform to the prescribed
pattern [1] which encodes the name of the TC (tc-shortname)
in the identifier, consistent with declared [3] namespace
names in XML

  http://docs.oasis-open.org/[tc-shortname]/ns/xxxx

Details:

Such identifiers may identify virtually anything of importance
in the scope of a specification: names for link relations,
properties, functions, faults, dialects, actions, or messages
(typed message names from a list of types). Anything that
needs to be named or enumerated can use these URI-based
identifier strings. [2]

The reason we require the TC name (tc-shortname) to be placed
in the identifier is so that OASIS can administer names without
the fear of collision.  In theory, two different specs from the
same TC could create conflicting identifiers, but if they
did so, the error is the TC's problem (for revision or errata).

OASIS TC Admin simply enforces the framework for assignment
(allocation, management) of names by requiring incorporation
of the TC name in the prescribed pattern.  We do not have any
other administrative mechanism for management of names in
(name) spaces, and we have no scalable technical solution
for any applicable server-level functions if TCs could mint
ad hoc names of any just kind based just upon http://.

Finally, it should be obvious from the above that one OASIS
TC cannot declare formal identifiers using the "tc-shortname"
of a different TC: each TC manages names/identifiers in its
own namespace, and in no others.  Similarly, a Work Product
should not create identifiers based upon (Internet Domain)
names owned by other organizations, and organizations outside
OASIS cannot create (valid) identifiers using the Internet
Domains owned by OASIS (e.g., oasis-open.org, as in HTTP
scheme: http://docs.oasis-open.org ).

====== Refs:

[1] namespace name construction and associated identifiers
http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#ns-URI-string-rules

[2] identifiers for properties, actions, messageTypes, etc
http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#nonInformationResources

[3] XML namespace name declaration (using a family of reserved attributes)
http://www.w3.org/TR/2009/REC-xml-names-20091208/#dt-NSDecl

======

[4] WD03  [-wd03  still has the errant identifier strings

WS-Calendar Calendar Update and Synchronization with REST-based Services Version 1.0

Working Draft 02

http://www.oasis-open.org/committees/download.php/45178/ws-calendar-rest-v1.0-wd03.pdf




On Mon, Feb 13, 2012 at 1:59 PM, Robin Cover <robin@oasis-open.org> wrote:
On Mon, Feb 13, 2012 at 1:39 PM, Considine, Toby (Campus Services IT) <Toby.Considine@unc.edu> wrote:

Thanks

 

Ignorance not deliberate.


Thanks, Toby.  One of my favorite quotes, because it applies to
me so often:

  "There's only one cure for ignorance: knowledge."
 
- Robin

PS  I'm guessing that the same issue of property identifier
(and/or namespace) construction is relevant to the
SOAP-based services spec.

 

Mike, can we fix this by Wednesday?

 

tc

 

From: ws-calendar@lists.oasis-open.org [mailto:ws-calendar@lists.oasis-open.org] On Behalf Of Robin Cover
Sent: Monday, February 13, 2012 1:39 PM
To: OASIS WS-Calendar TC List
Cc: Robin Cover; Chet Ensign; Paul Knight; Anne Hendry
Subject: [ws-calendar] construction pattern for property identifiers in the REST spec

 

Hi Toby.

 

WRT the draft spec for the REST spec

"WS-Calendar Calendar Update and Synchronization with REST-based Services Version 1.0"

 

I was a bit surprised to see the creation of property

identifiers using the domain "docs.oasis-open.org/"

where the identifiers don't follow the expected pattern.

 

Maybe this was was discussed in connection with other

WS-Calendar TC spec approvals, but I don't recall it...

 

I say "surprised" because we do indeed authorize the

creation of identifiers for properties based upon

URNs or HTTP-scheme URIs, but when the Internet domain

"docs.oasis-open.org" is used, there's a restriction

on construction of the identifier string for any

"properties" (namespace), per details cited at [3]

below.

 

WD text was:

 

  3.  Properties and link relations

  3.1 Property and relation-type URIs

 

  "Certain of these property URIs correspond to CalDAV

   preconditions. Each URL is prefixed by the CalWS

   relations and properties namespace:

 

(attested strings)

 

Please let me know if there are any issues.  For properties,

we would expect something like this in the initial identifier

substring:

 

   [newer model]

 

In both patterns, the TC name (tc-shortname) is required,

because identifiers are allocated/managed on a TC-by-TC

basis.  The TC "owns" that space of names/identifiers.

 

Following the initial substring, per above, you could use

anything else (reasonable) like:

 

wscal/calws/caldav/

wscal/calws/calws/

wscal/calws/

wscal/[xxxx]/

calws/[xxxx]/

 

in the pattern to construct identifiers that terminate with

(e.g.,) these substring elements/compnents

 

- supported-calendar-data

- calendar-collection

- timezone-service

- child-collection

- collection

- created

- current-principal-freebusy

- description

- displayname

- last-modified

- max-attendees-per-instance

- max-date-time

etc

 

- Robin

 

 

[1] XML Namespace Identifiers and Namespace Documents

 

 

[3] Non-information resources

 

    "Non-information resources using identifiers associated with XML

    namespaces may be based upon any HTTP scheme URI XML namespace

    declared by the TC (i.e., identifiers for named properties,

    functions, dialects, faults, actions, or any named message types).

    Example: see the Link Relations URIs in one of the CMIS v1.0 XML

    namespace documents (e.g.,

 

 

--
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/people/staff/robin-cover
Cover Pages: http://xml.coverpages.org/
Newsletter: http://xml.coverpages.org/newsletterArchive.html
Tel: +1 972-296-1783




--
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/people/staff/robin-cover
Cover Pages: http://xml.coverpages.org/
Newsletter: http://xml.coverpages.org/newsletterArchive.html
Tel: +1 972-296-1783



--
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/people/staff/robin-cover
Cover Pages: http://xml.coverpages.org/
Newsletter: http://xml.coverpages.org/newsletterArchive.html
Tel: +1 972-296-1783

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]