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

Hi Jose,

Good stuff!

On the question of extensions, I don't disagree with your subclass
approach to additional properties, but .... :-)

Having the ability to associate namespaces and prefixes would allow
extensions that didn't require different classes to be implemented. All
that would change would be the name of the property. I might ask for
"displayWidth", a name in the default namespace, or
"mm:specialMyMobileWebProperty" a name from the MyMobileWeb namespace. The
API calls would be identical.

Also, in some languages, subclassing might be problematic.

Best wishes
Rhys


  _____

From: jmcf@tid.es [mailto:jmcf@tid.es]
Sent: 11 October 2007 10:11
To: Rhys Lewis
Cc: public-ddwg@w3.org
Subject: Re: [API] Two comments about the DDR API document


Rhys Lewis escribió:

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.



This is what is actually done in the current draft of the Java API, there
is a class called DDRPropertyHelper that by default establishes the
namespace of the property to be the default DDR Vocabulary namespace :) .
This is the advantage of representing a property as an interface in the
API, that it can be very easy to support different namespaces via
"convenience classes".


All that is necessary, in addition, is an API call that associates a

prefix with a namespace.



I'm not sure that we are going to need that. I would say that it is not
necessary as I can always create a convenience class that implements the
DDRProperty interface and hides the namespace behind that. See below

import org.w3c.ddr.DDRProperty;

public class MyMobileWebProperty implements DDRProperty {

    private String id;

    public  MyMobileWebProperty(String id) {
        this.id = id;
    }

    public String getId() {
        // TODO Auto-generated method stub
        return id;
    }

    public String getNamespace() {
        // TODO Auto-generated method stub
        return "http://www.morfeo-project.org/mymobileweb/vocabulary"
<http://www.morfeo-project.org/mymobileweb/vocabulary> ;
    }

}

Best Regards


Best wishes

Rhys





-----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:1.8.1.7) Gecko/20070914

Firefox/2.0.0.7\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