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


Thanks

 

Ignorance not deliberate.

 

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



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