From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Sat, 12 May 2007 07:37:06 -0600

On May 11, 2007, at 12:02 AM, Daniel E. Renfer wrote:
>
> I have just very recently been reading up about WADL and have been
> trying to map the URLs in my web site/application. I've encountered
> some issues, and have a few suggestions for a future draft of WADL.
>
> First, how would I reference the root of my domain? From reading the
> spec, it looks like I need to just do @path="" but that looks wrong to
> me. The schema agrees with it, and Mark's stylesheet handles it
> correctly, but having an empty attribute like that just feels wrong.

An empty @path is the right way to do it.

> Which brings me to my next point.
>
> Is there any reason that the path attributes were designed to not
> include the leading "/" character? (like almost every other product
> I've seen that uses paths does.) Was it simply a matter of it could've
> gone one way or the other and it was a matter of preference on behalf
> of the original author, or is there some other technical reason I'm
> not aware of?
>
The idea is that a resource is relative to its parent (resource or
resources). When you resolve a relative URI that starts with a '/'
then you replace the entire path of the base URI rather than append
to the existing path so it seemed more in keeping with how relative
URIs works to omit a leading '/' than include one.

> If it was just a matter of preference, and there are no other specs
> out there that say it has to be done this way, I'd like to offer my
> recommendations to section 2.5.1
>
> 1) Allow @path segments to begin with a leading slash. If the
> identifier at this point ends with a slash, and the path begins with a
> slash, then the leading slash on the path is dropped. (only one slash
> in final identifier)
> 2) If neither the identifier or the path contain the slash character
> in their appropriate positions, then a slash is added between them,
> unless the resource element contains a @omit-path-separator="true"
> attribute. (subject to better name)
>
> The first rule would allow people to start their @path segments with
> or without a slash according to taste without breaking existing WADL
> documents. The second rule would allow people to nest resource
> elements without each level introducing another path. With these two
> rules, it would be possible to do things like this:
>
> <resources base="http://www.example.com/">
> <resource path="/">
> <resource path="news/{year}" omit-path-separator="true">
> <param name="year" style="template" type="xs:int"/>
> <resource path="-{month}" omit-path-separator="true">
> <param name="month" style="template" type="xs:int"/>
> <resource path="-{day}" omit-path-separator="true">
> <param name="day" style="template" type="xs:int"/>
>
> This would allow URLs such as:
> http://www.example.com/
> http://www.example.com/news/2007
> http://www.example.com/news/2007-5 (anyone know if xs:int has
> a problem with '05'?)
> http://www.example.com/news/2007-5-11
>
Not sure I really like nested resource elements for that kind of
usage, I think the following is more readable:

<resources base="http://www.example.com/news">
   <resource path="{year}">
     ...
   </resource>
  <resource path="{year}-{month}">
     ...
   </resource>
   <resource path="{year}-{month}-{day}">
     ...
   </resource>
</resources>

Thanks,
Marc.

---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.