W3C home > Mailing lists > Public > public-ddwg@w3.org > October 2007

RE: [API] Two comments about the DDR API document

From: Rhys Lewis <rhys@volantis.com>
Date: Thu, 11 Oct 2007 01:38:37 -0600 (MDT)
To: "'Rotan Hanrahan'" <rotan.hanrahan@mobileaware.com>, "'Ignacio Marin'" <ignacio.marin@fundacionctic.org>, <public-ddwg@w3.org>
Message-ID: <009f01c80bda$25d1c660$981e140a@volantisuk>

Hrrmph! I guess I have to put my TAG hat on here!

Extensions should be identified by namespaces. Compact representations
should be QNames. So, we should be talking about prefixes not integers.

By the way, DCCI [1] already uses namespaces, but doesn't have an
equivalent of prefixes.

The API could of course specify some defaults. For example, the default
namespace is the DDR core vocabulary. There might be 'standard' extensions
whose prefixes are well known and built in by default.

All that is necessary, in addition, is an API call that associates a
prefix with a namespace.

Best wishes

> -----Original Message-----
> From: public-ddwg-request@w3.org
> [mailto:public-ddwg-request@w3.org] On Behalf Of Rotan Hanrahan
> Sent: 10 October 2007 23:25
> To: Ignacio Marin; public-ddwg@w3.org
> Subject: RE: [API] Two comments about the DDR API document
> The problem with using integers for extensions by third
> parties is that you need someone to manage the process so
> that the numbers remain unique. Otherwise different third
> parties might use the same integers, and later when someone
> tries a mashup of the technologies, you get chaos. That's an
> overhead that needs to be avoided. Namespacing comes to mind
> as a better mechanism. A hybrid approach would be to
> associate the integers with namespaces (i.e. a couple). And
> we can then define the default namespace to be that of the
> DDWG, thus making the core methods and vocabulary the defaults.
> Obviously we have to design for extensibility, but we have to
> ensure that the extensibility will function unmanaged.
> Generally, I agree with you Nacho that the IdentifyBy*
> functions need to be more flexible.
> As for your second point, HTTP allows for any field-name to
> be used, although it pre-defines the semantics of several
> (e.g. User-Agent). As the HTTP protocol permits additional
> headers, you cannot fail because the headers include some you
> don't recognise. The protocol requires you to treat those as
> "Extension Entity Headers". The protocol also requires these
> headers to be forwarded, though the eventual recipient is
> free to ignore them. So, in fact, by allowing the extension
> headers to be used in the DDR API, we're actually following
> the guidance given in RFC 2616.
> ---Rotan.
> ________________________________
> From: public-ddwg-request@w3.org on behalf of Ignacio Marin
> Sent: Wed 10/10/2007 22:58
> To: public-ddwg@w3.org
> Subject: [API] Two comments about the DDR API document
> Hello everyone,
> Here I come with two comments in order to start the
> discussion about the DDR API document (Editor's Draft version
> 1b sent by Jo [1]) so we all can make it evolve.
> First comment (IdentifyBy* functions):
> -------------
> There are two functions in the draft called
> IdentifyByUAString and IdentifyByHTTPHeaders and there as
> been an unresolved discussion about whether both or them are
> necessary or not. But I think that there is a need for a more
> general function, taking into account that we want the DDR
> API to focus on the Web (we are working in a W3C WG) but
> never closing doors for its extension to other content adaptation.
> For instance, and following the description format for DDR
> functions used in [1], we might propose a function like:
> --------------------------------------------------------------
> IdentifyByString (alternative better names are welcome!)
> Inputs
>     String (string)
>       A string containing information allowing the
> identification of the browser and/or device. Its format is
> specified by input parameter "Format".
>     Format (unsigned integer? String?)
>         A unsigned integer (for me, but it is obviously open
> to discussion) declaring the format in which information is
> expressed in input parameter "String".
>     Single (boolean - default False)
>         Return only the best match if true, otherwise return
> a set of matches
> Outputs
>     Success
>         Values: Exact Match Found, Found, Not Found
>     Context Key
>         A Context Key opaquely referencing various component
> types and their alternatives
> Exceptions
>         tbd
> --------------------------------------------------------------
> An example:
>    idString = "User-Agent: Mozilla/5.0 (Windows; U; Windows
> NT 5.1; es-ES; rv: Gecko/20070914
> Firefox/\r\nAccept:
> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9
> ,text/plain;q=0.8,image/png,*/*;q=0.5\r\n....";
>    [success, contextKey] = IdentifyByString(idString,
> HTTP_HEADERS, false);
> Where HTTP_HEADERS might be a symbolic constant representing
> the unsigned integer value of 1.
> This would be the same as using IdentifyByHTTPHeaders. In
> fact, IdentifyByHTTPHeaders would now be a convenience function.
> Another example would be a string including RTSP headers (if
> I want to cover content adaptation for media streaming). So
> the idString would have a sequence of RTSP headers in a
> format very similar to HTTP 1.1, but with the input parameter
> "Format" with a value of 2 for instance (expressed maybe by
> the corresponding RTSP_HEADERS symbolic constant).
> One more example: we might try to identify, as said several
> times within this group, by IMEI. Just use a new value for
> "Format" (3, for instance), write the IMEI in the String
> input parameter... et voilá.
> DDWG would only set some values for the "Format" input
> parameter (maybe only one is needed: for HTTP Headers) but
> would let the door open for extensions of the DDR API to
> other organizations, companies, etc. willing to deal with
> RTSP, IMEIs and whatever.
> What do you think about this approach?
> While you answer, I shall cover my second comment.
> Second comment (What is an HTTP Header? O:-) ):
> --------------
> When we are talking about HTTP headers, being a W3C working
> group, we should only expect that. I mean... Should we
> support proprietary headers, just like HTTP_UA_PIXELS and many others?
> If non standard HTTP headers are included, being a purist,
> anything out of the HTTP spec should make (for example)
> IdentifyByHTTPHeaders raise an exception.
> I was just thinking out loud. I'd personally allow those HTTP
> "extensions", but I fear that we go on as the developers we
> are, and afterwards someone blames our API for not following
> [2]. There is a good excuse to avoid this issue: leave that
> subject open to implementations. Anyway, it might be good to
> make a comment anywhere in the DDR API doc.
> Best regards,
> Nacho
> [1] http://www.w3.org/2005/MWI/DDWG/drafts/api/070831
> [2] http://www.w3.org/Protocols/rfc2616/rfc2616.html
Received on Thursday, 11 October 2007 07:38:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:00:15 UTC