W3C home > Mailing lists > Public > uri@w3.org > August 2007

Re: URI Templates - optional variables?

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 1 Aug 2007 15:02:35 -0700
Message-Id: <C7723B83-9546-403A-9D8F-1485FD46FC51@gbiv.com>
Cc: Joe Gregorio <joe@bitworking.org>
To: uri@w3.org

I still think that URI templates need to define a syntax for
defaulting and other common string substitutions, even if the
initial authors have no need of it.  The fact is that there are
a limited number of special characters left out of the URI syntax
specifically for allowing delimited expansions like templates.
Just because *this* application can live without it does not
justify its denial for all those other applications that might
need it.

Instead, the draft should define a syntax that is capable of
supporting more extensive (and perhaps application-specific
derivatives) and then only require a minimal subset be supported
by the authors' own class of applications.

For example, the following are all trivial to implement and allow
the simple case to be distinguished by the initial character:

    {variable}
         Substitute the value of variable.

    {=default:variable}
         If variable is defined and non-empty, then substitute the
         value of variable.  Otherwise, substitute with the default
         value defined by the string of non-colon characters between
         the '=' and ':', if any.
             E.g.,  {=red:favoritecolor}  = "value" or "red"

    {?prefix:variable}
         If variable is defined and non-empty, then substitute the
         string of non-colon characters between the '?' and ':', if
         any, followed by the value of variable.  Otherwise, substitute
         with the empty string.
            E.g.,   {?/:variable}       = "/value"      or ""
                    {?;name=:variable}  = ";name=value" or ""
                    {?#:variable}       = "#value"      or ""

    {%separator:hashvar}
         For each variable named in the value of hashvar (which could
         be a space-separated string or some context-dependent hash
         mechanism), if the named variable is defined and non-empty,
         then substitute the concatenation of variable name, "=",
         variable value.  If more than one substitution is made,
         separate each substitution with the string of non-colon
         separator characters between the '%' and ':'.
            E.g.,   myhash = "name age sex location"
                      name = "Fred"
                       age = "41"
                       sex = ""
                  location = "USA"

            then  {%&:myhash} = "name=Fred&age=41&location=USA"

    {-offset:variable}
    {-offset-length:variable}
         Substitute a substring of the value of variable, as delimited
         by the non-negative integer offset from the beginning of the
         value string (0 = start of string) and including the remaining
         characters (if any) up to the maximum given by the positive
         integer length.  offset must be in the range [0-255].  length
         must be in the range [1-256].
             E.g.,  {-0-3:variable}     = "val" or ""
                    {-3-2:variable}     = "ue"  or ""
                    {-3-8:variable}     = "ue"  or ""
                    {-2:variable}       = "lues"  or ""


I'll bet that will satisfy every common use case, short of regular
expression substitutions, without being a burden to implementors.
And, just in case it doesn't, reserve the other non-variable-name
first characters for future extensions.  That way, if such an unknown
character is found at the beginning of the template, all current
implementations can recognize it as an extension even if they don't
understand the extension yet.


Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>
Received on Wednesday, 1 August 2007 22:02:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:11 UTC