[KI-LC] Proposal for LC guideline for URI naming in technical specs

Eve Maler eve at xmlgrrl.com
Tue Aug 30 21:54:15 EDT 2011


Hi folks-- Sorry for the delay on this. Here is my proposal for the URI naming guideline. Hopefully we can discuss it tomorrow.  Thanks!

	Eve

http://kantarainitiative.org/confluence/display/LC/URI+Naming+in+Technical+Specifications

Requirements
Kantara Work Groups that produce Technical Specifications often need to give unique labels to various components in those specifications, such as XML namespace names, or identifiers for fields in XRD descriptive data. Although these labels are intended to be temporary until the specs are eventually completed at a standards development organization (SDO), software implementers often need to code features that use these draft labels in the interim.

Uniform Resource Identifiers (URIs), most often Uniform Resource Locators (URLs) using the http: scheme, are typically used for such labels. In some cases, it's desirable to allow machine-readable metadata, such as a schema, to be retrieved from the URL.

Kantara Work Groups have control of URLs that reside in the wiki area assigned to them (for example,http://kantarainitiative.org/confluence/display/uma/... for the UMA Work Group), but using such URLs has two downsides:

Wiki areas are managed by the Confluence software in a proprietary fashion, and it's difficult to place "unencumbered" metadata at such locations.
The URLs are longer than strictly necessary, making code examples difficult to read.
Following is an example from the UMA 1.0 Core Protocol illustrating the need for labels in its XRD formats (using entirely made-up URLs):

<!-- Applies to both hosts and requesters -->

<Property
  type="http://kantarainitiative.org/ns/uma/1.0/token_formats">artifact
</Property>
<Property
  type="http://kantarainitiative.org/ns/uma/1.0/claim_formats">claims2
</Property>

<!-- Host protection API -->

<!-- AM as authorization server to host-as-client -->
<Link
  rel="http://kantarainitiative.org/ns/uma/1.0/host_token_uri"
  href="https://am.example.com/host/token_uri">
</Link>
<Link
  rel="http://kantarainitiative.org/ns/uma/1.0/host_user_uri"
  href="https://am.example.com/host/user_uri">
</Link>
...
LC Guideline Proposal
Kantara should make available the following area on its site that Work Groups can use for URL-based labels and, optionally, web resources that correspond to these labels: http://docs.kantarainitiative.org/.

Each Work Group should, by request to Kantara staff, be given the opportunity to control URLs and content in an area named with the same affix given to their Confluence wiki area (or a modified affix by mutual arrangement). For example, the UMA Work Group could requesthttp://docs.kantarainitiative.org/umawg/ or http://docs.kantarainitiative.org/uma/.

Within such an area, the Work Group would have the opportunity to manage the namespace as it sees fit, for example, including version or date numbers or spec module names as URL path components.

Technical Specifications that make use of such URLs must make clear that they are to be considered temporary until such time as the specification is finalized in an SDO.

Work Groups could choose to use some other system of labeling, such as URNs, or URLs in a non-Kantara-related domain (with permission of the domain owner), but if they want to use the kantarainitiative.org domain, it must be as prescribed in this policy.

References
For somewhat similar policies, see:

The OASIS naming directives
The URIs for W3C Namespaces policy


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/lc/attachments/20110830/c370fdfc/attachment.html 


More information about the LC mailing list