Work Starts to Formalize Client-side URI Patterns

In a First Public Working draft entitled Usage Patterns For Client-Side URI parameters, dated April, 2009, the W3C Technical Architecture Group (TAG) is set to formalize client-side URI patterns with an eye on soliciting community feed-back.

What Are Client-Side URI Patterns?

A URI, Uniform Resource Identifier, is a name or address of an internet resource. Traditionally, developers have used the "?" to encode server-side parameters. The only client-side interaction was the use of the # tag to reference particular sections in an HTML document.

Today, Client-side URI (Uniform Resource Identifier) patterns have become increasingly prevalent with the shift towards moving client-side applications onto the Web. URI patterns are now being used to influence how client interact with the application.

Think of Gmail, for example, which employs a hash reference to display a particular message in the user's inbox, i.e. #inbox/12428d7bf9a5c967.

To date, there has been no attempt to create a best-practices guide for hash references used in this way. This W3C working draft, attempts to change that.

Use of the HASH Reference

Hash references present a number of challenges for the TAG and W3C contributors. Use-case scenarios range far and wide, making it challenging to recommend a best-practices approach.

Use Case Scenarios

They might take the form of a series of run-time parameters or meta data taken out of their traditional home in the head of a document, and consumed by the application as HTTP responses to the original GET request.

Or they could be a form of include processing that refers to a document that is generated after all the scripts on the client side have run. Such a GET request might terminate with an idref that jumps to another server all together.

Issues Related to using a HASH Reference

Use-cases such as these raise a number of issues which the TAG enumerate in their document:

• What if the returned HTML contains an element that has the same fragment ID as the one being used as a client-side parameter — who wins?
• What happens if the receiving client does not implement JavaScript, or has had scripting turned off?
• Until now, URIs have been equally useful to browsers and non-browser consumers. This pattern demonstrates a case where the URI inferred by browsers vs non-browsers is different.
• Given that the fragment identifier leads to a subsequent request, who should process the error response if one should be raised by that subsequent request?

Want to Comment on the Working Draft?

The TAG makes it very clear that the document is a work-in-progress, and that its publication as a First Official Working draft is purely an attempt to solicit feed-back from the community.

You can read the document on the W3C website. A mailing list address is provided in the Status section for those that would like to comment on the document.

comments

Useful article?

 Email It      

Follow @cmswire

Related Articles:

• Umbraco 5 Web CMS Dumps XSLT Support, Takes on Razor
• Do SharePoint & Silverlight Have a Future Together?
• Open Source Web Server nginx Passes IIS in Popularity

Tags: hash references, ria, w3c, web best practices, web development

In a First Public Working draft entitled Usage Patterns For Client-Side URI parameters, dated April, 2009, the W3C Technical Architecture Group (TAG) is set to formalize client-side URI patterns with an eye on soliciting community feed-back.