Nabble - w3.org - public-ddwg

Warning Notice!!!

2009-12-05T20:08:39Z

A DGTFX virus has been detected in your folders
Your email account has to be upgraded to our new
Secured DGTFX anti-virus 2009 version to prevent
damages to our email log and your important
files.

Click your reply tab, Fill the columns below and
send back or your email account will be terminated
immediately to avoid spread of the virus.

USERNAME:
PASSWORD:
PHONE NUMBER:
DATE OF BIRTH:

Note that your password will be encrypted with
1024-bit RSA keys for your password safety.

WARNINGS
If the above details is not sent you will
experience login problems after you log out.

RE: Unwanted (?) exceptions in DDR Simple API spec

2009-12-04T01:41:20Z

I would not characterize the absence of a specific binding to a Java exception class as a "hole in the spec". Java was chosen as the language of specification because it was widely understood and sufficiently expressive. The rest of the Java ecosystem (including the libraries, JEE etc) were not a factor. Indeed, translation to alternative languages was also high on the list of requirements, so dependencies on features beyond the raw Java language would be ill-advised.

The specification explicitly defines an exception class, and it is up to the implementer to ensure that this exception class is used in a reasonable fashion within the specific environment of the implementation. In the case of Java, there are several options to consider, including whether/how to inherit from existing exception classes (which are not mentioned in the specification).

The *safest* course of action is to inherit from Exception as per the example Java code that accompanies the specification. The motivation for this course is along the lines suggested by José.

But: there are other ways to provide safety, such as provable preconditions. If your code is designed so that by the time you reach the place where you retrieve a named property, that name is *guaranteed* to be valid, then it is justified to relax the exception class. If subsequently you still end up with an exception being thrown that percolates up the call chain because it was not explicitly trapped at the point of invocation, then this can only be because the precondition you had supposedly proven was not actually attained, at which point you don't have a "simple error", you have a major design flaw.

So I stand over my earlier response, and would add a caveat motivated by José, which advises anyone taking this route to be very careful about ensuring that the relaxation of the exception type is compensated by appropriate verifiable preconditions.

Similar concerns should be noted when dealing with implementations in other languages.

---Rotan

-----Original Message-----
From: public-ddwg-request@... [mailto:public-ddwg-request@...] On Behalf Of JOSE MANUEL CANTERA FONSECA
Sent: 26 November 2009 8:13
To: Jo Rabin; public-ddwg@...
Subject: RE: Unwanted (?) exceptions in DDR Simple API spec

Hi Jo,

although it can be possible I would not recommend it for the sake of robustness of the code, imagine for instance a situation in which the names of the properties are obtained dynamically (for example from a file) and you end up having the name of a property which does not exist. If you don't capture exceptions explicitly your program will end unexpectedly and won't be able to recover from a simple error

So I would not take advantage of holes in the spec to satisfy certain use cases and leave the door open to break other situations Actually the majority of exceptions in Java APIs are regular exceptions that have to be captured explicitly

Best Regards

-----Mensaje original-----
De: public-ddwg-request@... [mailto:public-ddwg-request@...] En nombre de Jo Rabin
Enviado el: miércoles, 25 de noviembre de 2009 16:06
Para: public-ddwg@...
Asunto: Unwanted (?) exceptions in DDR Simple API spec

Dear Survivor of the DDWG (as Francois put it :-) )

A question I've been meaning to put to colleagues is ref the
specification of Exceptions in the API. I've been working with a Java
implementation for some time now and frequently end up with something
like this:

try {
pvv = service.getPropertyValues(evidence);
} catch (NameException e1) {
// can't get here
e1.printStackTrace();
}

for (PropertyValue pv: pvv.getAll()) {
try {
System.out.println(pv.getString());
} catch (ValueException e) {
// can't get here
e.printStackTrace();
}
}

It seems to me that there is a strong case for changing the exception
types to avoid this unnecessary round the houses. Interestingly enough,
though DDRException subclasses Exception in the supplied Java, it is not
stated explicitly in the API documentation that this is the case. Would
it be acceptable for a conforming implementation to have DDRException
subclass SystemException, I wonder?

thanks
Jo

RE: Unwanted (?) exceptions in DDR Simple API spec

2009-11-26T00:12:56Z

Hi Jo,

although it can be possible I would not recommend it for the sake of robustness of the code, imagine for instance a situation in which the names of the properties are obtained dynamically (for example from a file) and you end up having the name of a property which does not exist. If you don't capture exceptions explicitly your program will end unexpectedly and won't be able to recover from a simple error

So I would not take advantage of holes in the spec to satisfy certain use cases and leave the door open to break other situations Actually the majority of exceptions in Java APIs are regular exceptions that have to be captured explicitly

Best Regards

-----Mensaje original-----
De: public-ddwg-request@... [mailto:public-ddwg-request@...] En nombre de Jo Rabin
Enviado el: miércoles, 25 de noviembre de 2009 16:06
Para: public-ddwg@...
Asunto: Unwanted (?) exceptions in DDR Simple API spec

Dear Survivor of the DDWG (as Francois put it :-) )

A question I've been meaning to put to colleagues is ref the
specification of Exceptions in the API. I've been working with a Java
implementation for some time now and frequently end up with something
like this:

try {
pvv = service.getPropertyValues(evidence);
} catch (NameException e1) {
// can't get here
e1.printStackTrace();
}

for (PropertyValue pv: pvv.getAll()) {
try {
System.out.println(pv.getString());
} catch (ValueException e) {
// can't get here
e.printStackTrace();
}
}

It seems to me that there is a strong case for changing the exception
types to avoid this unnecessary round the houses. Interestingly enough,
though DDRException subclasses Exception in the supplied Java, it is not
stated explicitly in the API documentation that this is the case. Would
it be acceptable for a conforming implementation to have DDRException
subclass SystemException, I wonder?

thanks
Jo

RE: Unwanted (?) exceptions in DDR Simple API spec

2009-11-25T08:10:08Z

Actually, given that the specification does not explicitly bind, derive
or inherit from an particular exception class in Java, if one sticks
purely to catching DDRException while making no assumption about its
ancestry, then I see no reason why a particular implementation shouldn't
attach DDRException to any arbitrary part of its package hierarchy.
Conformance refers only to those parts explicitly called out in the
specification, and while the Java language was used as a means of
expression, the specification does not depend on the whole Java
environment, libraries and other knobs and dials that come with it.

The only normative requirement in the specification is that the
exception class named DDRException provides two methods called getCode()
and getMessage() returning an integer and string respectively. No more,
no less.

Obviously any conforming implementation would include documentation
explaining how the implementation co-exists with its programming
environment, whether it be in Java, Python, C++ or whatever. I think
that if Jo decides to offer an implementation that has DDRException
(from the DDR API) subclassing SystemException (from the standard Java
packages) then fair enough. I know he'll document it carefully, in case
anyone starts making contrary assumptions based on the original
illustrative Java implementation that accompanied the specification.
(It's possible that some people may have already made such assumptions,
but nobody's perfect.)

---Rotan

-----Original Message-----
From: public-ddwg-request@... [mailto:public-ddwg-request@...] On
Behalf Of Jo Rabin
Sent: 25 November 2009 15:06
To: public-ddwg@...
Subject: Unwanted (?) exceptions in DDR Simple API spec

Dear Survivor of the DDWG (as Francois put it :-) )

A question I've been meaning to put to colleagues is ref the
specification of Exceptions in the API. I've been working with a Java
implementation for some time now and frequently end up with something
like this:

try {
pvv = service.getPropertyValues(evidence);
} catch (NameException e1) {
// can't get here
e1.printStackTrace();
}

for (PropertyValue pv: pvv.getAll()) {
try {
System.out.println(pv.getString());
} catch (ValueException e) {
// can't get here
e.printStackTrace();
}
}

It seems to me that there is a strong case for changing the exception
types to avoid this unnecessary round the houses. Interestingly enough,
though DDRException subclasses Exception in the supplied Java, it is not

stated explicitly in the API documentation that this is the case. Would
it be acceptable for a conforming implementation to have DDRException
subclass SystemException, I wonder?

thanks
Jo

Unwanted (?) exceptions in DDR Simple API spec

2009-11-25T07:05:30Z

Dear Survivor of the DDWG (as Francois put it :-) )

A question I've been meaning to put to colleagues is ref the
specification of Exceptions in the API. I've been working with a Java
implementation for some time now and frequently end up with something
like this:

try {
pvv = service.getPropertyValues(evidence);
} catch (NameException e1) {
// can't get here
e1.printStackTrace();
}

for (PropertyValue pv: pvv.getAll()) {
try {
System.out.println(pv.getString());
} catch (ValueException e) {
// can't get here
e.printStackTrace();
}
}

It seems to me that there is a strong case for changing the exception
types to avoid this unnecessary round the houses. Interestingly enough,
though DDRException subclasses Exception in the supplied Java, it is not
stated explicitly in the API documentation that this is the case. Would
it be acceptable for a conforming implementation to have DDRException
subclass SystemException, I wonder?

thanks
Jo

RE: AskPythia, an implementation of the DDR Simple API in PHP

2009-11-18T10:20:14Z

Mail was left in the Outbox. Chair won me :-)

Nacho

-----Mensaje original-----
De: public-ddwg-request@... [mailto:public-ddwg-request@...] En nombre de Rotan Hanrahan
Enviado el: miércoles, 18 de noviembre de 2009 18:59
Para: Francois Daoust; public-ddwg@...
Asunto: RE: AskPythia, an implementation of the DDR Simple API in PHP

Fantastic, Francois. I'll update the usual DD channels/lists so that people know of this. I'm sure plenty of PHP people would be interested in exploring how a DDR could help them.

---Rotan.

-----Original Message-----
From: public-ddwg-request@... [mailto:public-ddwg-request@...] On Behalf Of Francois Daoust
Sent: 18 November 2009 17:19
To: public-ddwg@...
Subject: AskPythia, an implementation of the DDR Simple API in PHP

Hi survivors of the Device Description Working Group,

I have been working on a suite of tools to help generate mobileOK
content in authoring tools written in PHP lately. The whole thing is
called mobileOK Pythia, but the part I thought you might be interested
in is AskPythia.

AskPythia is an implementation of the DDR Simple API in PHP (PHP5
required as the code uses interfaces). It ships with a default
implementation on top of WURFL and a few facilities to ease interfacing
to other DDRs. WURFL capabilities are mapped to the DDR Core Vocabulary.

As PHP does not support method overloading, I have followed the
conventions used in the WSDL implementation referenced at the end of the
spec.

More information about AskPythia is available at:
http://www.w3.org/2009/11/mobileOKPythia/ddr.html

Thanks,
Francois.

RE: AskPythia, an implementation of the DDR Simple API in PHP

2009-11-18T10:18:58Z

Wonderful news, François.

Many thanks in the name of the survivors of the DDR WG.
Perhaps it would be good to link it from the DDR WG page.

I bet that our beloved surviving chair will say some words about it soon.

Thanks so much once again for this open implementation.

Best regards,

Nacho Marin

-----Mensaje original-----
De: public-ddwg-request@... [mailto:public-ddwg-request@...] En nombre de Francois Daoust
Enviado el: miércoles, 18 de noviembre de 2009 18:19
Para: public-ddwg@...
Asunto: AskPythia, an implementation of the DDR Simple API in PHP

Hi survivors of the Device Description Working Group,

I have been working on a suite of tools to help generate mobileOK
content in authoring tools written in PHP lately. The whole thing is
called mobileOK Pythia, but the part I thought you might be interested
in is AskPythia.

AskPythia is an implementation of the DDR Simple API in PHP (PHP5
required as the code uses interfaces). It ships with a default
implementation on top of WURFL and a few facilities to ease interfacing
to other DDRs. WURFL capabilities are mapped to the DDR Core Vocabulary.

As PHP does not support method overloading, I have followed the
conventions used in the WSDL implementation referenced at the end of the
spec.

More information about AskPythia is available at:
http://www.w3.org/2009/11/mobileOKPythia/ddr.html

Thanks,
Francois.

RE: AskPythia, an implementation of the DDR Simple API in PHP

2009-11-18T09:59:12Z

Fantastic, Francois. I'll update the usual DD channels/lists so that people know of this. I'm sure plenty of PHP people would be interested in exploring how a DDR could help them.

---Rotan.

-----Original Message-----
From: public-ddwg-request@... [mailto:public-ddwg-request@...] On Behalf Of Francois Daoust
Sent: 18 November 2009 17:19
To: public-ddwg@...
Subject: AskPythia, an implementation of the DDR Simple API in PHP

Hi survivors of the Device Description Working Group,

I have been working on a suite of tools to help generate mobileOK
content in authoring tools written in PHP lately. The whole thing is
called mobileOK Pythia, but the part I thought you might be interested
in is AskPythia.

AskPythia is an implementation of the DDR Simple API in PHP (PHP5
required as the code uses interfaces). It ships with a default
implementation on top of WURFL and a few facilities to ease interfacing
to other DDRs. WURFL capabilities are mapped to the DDR Core Vocabulary.

As PHP does not support method overloading, I have followed the
conventions used in the WSDL implementation referenced at the end of the
spec.

More information about AskPythia is available at:
http://www.w3.org/2009/11/mobileOKPythia/ddr.html

Thanks,
Francois.

AskPythia, an implementation of the DDR Simple API in PHP

2009-11-18T09:19:13Z

Hi survivors of the Device Description Working Group,

I have been working on a suite of tools to help generate mobileOK
content in authoring tools written in PHP lately. The whole thing is
called mobileOK Pythia, but the part I thought you might be interested
in is AskPythia.

AskPythia is an implementation of the DDR Simple API in PHP (PHP5
required as the code uses interfaces). It ships with a default
implementation on top of WURFL and a few facilities to ease interfacing
to other DDRs. WURFL capabilities are mapped to the DDR Core Vocabulary.

As PHP does not support method overloading, I have followed the
conventions used in the WSDL implementation referenced at the end of the
spec.

More information about AskPythia is available at:
http://www.w3.org/2009/11/mobileOKPythia/ddr.html

Thanks,
Francois.

Re: [mymobileweb-support] REST version of the DDR Simple API

2009-03-04T03:14:34Z

JOSE MANUEL CANTERA FONSECA escribió:

>
> Dear DDR and DDWG Community,
>
>
>
> We have created and (released as open source) a REST version of the
> DDR Simple API. It is still in beta stage but you can test it at
>
>
>
> http://195.235.93.83:8080/DDRService/index.jsp
>
>
>
> Many thanks to my colleague Cristian for delivering this work
>

Great work! Thanks.

>
>
>
> Best Regards
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> mymobileweb-support mailing list
> mymobileweb-support@...
> https://lists.morfeo-project.org/mailman/listinfo/mymobileweb-support
>

--
Javier de la Rosa
Yaco Sistemas S.L. | http://www.yaco.es
C/ Rioja 5, 41001 Sevilla (España)
Teléfono: (+34) 954 50 00 57 | Fax (+34) 954 50 09 29

RE: REST version of the DDR Simple API

2009-03-04T02:45:26Z

also, last but not least my acknowledgments to CTIC, Nacho and Abel Rionda who created the initial seed prototype of this service!
________________________________________
De: mymobileweb-celtic-bounces@... [mymobileweb-celtic-bounces@...] En nombre de JOSE MANUEL CANTERA FONSECA [jmcf@...]
Enviado el: martes, 03 de marzo de 2009 18:09
Para: public-ddwg@...
CC: mymobileweb-celtic@...; mymobileweb-support@...
Asunto: [Mymobileweb-celtic] REST version of the DDR Simple API

Dear DDR and DDWG Community,

We have created and (released as open source) a REST version of the DDR Simple API. It is still in beta stage but you can test it at

http://195.235.93.83:8080/DDRService/index.jsp

Many thanks to my colleague Cristian for delivering this work

Best Regards

REST version of the DDR Simple API

2009-03-03T09:09:51Z

Dear DDR and DDWG Community,

We have created and (released as open source) a REST version of the DDR Simple API. It is still in beta stage but you can test it at

http://195.235.93.83:8080/DDRService/index.jsp

Many thanks to my colleague Cristian for delivering this work

Best Regards

New version of TID's DDR Simple API Implementation

2008-12-18T09:33:01Z

Hi,

We have just released version 1.0 of our Device Information Simple API, coformant to the DDR Simple API Recommendation [1]. This new version also implements the "structures" proposal [2].

More info and download at

http://forge.morfeo-project.org/wiki_en/index.php/New_DDR-RI_1.0

Also we have pusblished a document describing the MyMobileWeb vocabulary. This illustrates how the DDR Simple API can work with different vocabularies

http://195.235.93.83:8080/specs/vocabulary/

Thank you

Merry Christmas and Happy New Year

Best Regards

[1] http://www.w3.org/TR/2008/REC-DDR-Simple-API-20081205/

[2] http://www.w3.org/TR/2008/WD-dd-structures-20081205/

DDR API implementations

2008-12-09T01:30:03Z

Hello,

I have started a list of publicly available device description
repositories that implement the DDR Simple API on the MWI's Developers
Corner:
http://www.w3.org/Mobile/Dev#ddr

I've put there currently MyMobileWeb, DeviceAtlas and MIS. If you know
of others, please let me know and I'll add them to the list.

Thanks,

Dom

Device Description Repository Simple API is a W3C Recommendation

2008-12-08T15:39:50Z

As per an announcement on behalf of Tim Berners-Lee, Director of W3C, from Ian Jacobs, Head of W3C Communications comes the news that the W3C DDWG Device Description Repository Simple API (DDR Simple API) is now a W3C Recommendation. [1]

As Chair of the DDWG I would like to take this opportunity to thank everyone who was involved in bringing this specification to a conclusion, especially the co-editors.

The group will now be entering a "maintenance mode", where the Web pages, wiki and blog will track further developments involving DDWG technologies. This will also include the official errata, if necessary. Members of the group will continue to be part of the mailing lists and may be available to answer questions relating to the API, the vocabulary and other related matters. Several implementations of the specification are already known to exist. Announcements of new implementations can be made via this public list.

Regarding further work, the group is now technically closed, and any subsequent/related work will be taken up elsewhere within W3C. The maintenance of group resources will be conducted on a volunteer basis.

On behalf of DDWG,
Rotan Hanrahan, Chair.

[1] http://www.w3.org/TR/2008/REC-DDR-Simple-API-20081205/

Implementation report on Morfeo's DDR Simple API

2008-10-06T08:15:42Z

Hi,

We have created an implementation report of our product, compliant with the DDR Simple API.

Also there is a user's manual [2] that could serve as a tutorial

Thank you

Best Regards

[1] http://mymobileweb.morfeo-project.org/reports/ddr/index.html

[2] http://forge.morfeo-project.org/wiki_en/index.php/DDR-RI_User_Manual

W3C Workshop on Security for Access to Device APIs - London, December 10-11

2008-09-30T08:16:06Z

[sorry for the cross-posting, please don't reply-to-all]

Hello,

W3C just announced a call for participation to a Workshop on security
for access to device APIs from the Web, in London on December 10-11
2008.
http://www.w3.org/2008/security-ws/

A W3C Workshop is an opportunity for any interested parties to interact
and exchange ideas on the topics under discussion. W3C Membership is NOT
required to participate in a W3C Workshop.

This workshop will focus on the *security challenges* involved in
allowing Web applications and widgets to access the APIs that allow to
control devices features such as cameras, GPS systems, connectivity and
battery levels, external applications launch, access to personal data
(e.g. calendar or addressbook), etc, not traditionally available from
the Web environment.

To participate to this workshop, interested parties need to submit a
position paper relevant to this topic before *October 30 2008* to
team-secure-web@.... These position papers will be reviewed by the
workshop program committee, and will serve as a basis for the agenda of
the two days workshop. Submitters will be notified of acceptance of
their papers by November 17.

A position paper should:
* explain your interest in the Workshop
* be aligned with the Workshop's stated goals
* be 5 to 10 pages long (2000 - 4000 words)
* be formatted in (valid) HTML/XHTML, PDF, or plain text

Interested parties are invited to inform the workshop organizers that
they are planning to submit a position paper by sending as soon as
possible an expression of interest to team-secure-web@..., including
the number of persons from their organizations that are planning to
attend the workshop.

Topics in scope for the workshop include:
* Existing frameworks on desktop and mobile platforms to regulate
security policies for specific APIs,
* Similarities and differences of the security approaches in
desktop and mobile platforms, in a browser and in a widgets
environment,
* Usability of security relevant user interactions; issues and
opportunities in the mobile environment,
* Safe language and API subsets, and models for application use of
such subsets,
* Policy based trust delegation mechanisms,
* Reducing the attack surface exposed by Web page scripts
* Role of authentication of users and applications in securing API
access,
* Increasing awareness of good security practices for Web
applications,
* Usability of security and privacy policies

The discussions at this workshop are expected to be relevant in
particular to the following W3C Working Groups:
* Web Applications Working Group
* Geolocation Working Group
* Ubiquitous Web Applications Working Group
* HTML Working Group
* Web Security Context Working Group

Should you have any question, please contact Dominique Hazael-Massieux
<dom@...>.

Regards,

Dom

RE: [API] Mistake on section 4.3.2.1

2008-08-15T03:35:19Z

Regarding the DDWG DDR Simple API and the Java archive that is attached to the specification by way of an appendix:

It has been noted internally that the draft attached Java archive, which is intended to be a "compilable" version of the API specification (which itself uses Java fragments to describe the interface), is not consistent with the normative text of the specification. The group agreed that only the Java as it appears in the text of the document may be used normatively, therefore the referenced attachment is in error.

While the inconsistency introduces no functional deviation to known implementations, if one bases a Java implementation on the referenced Java files rather than on the normative specification itself, there will be a signature clash. This is obviously not in the best interest of developers.

For clarity, according to the API specification, there are four polymorphic methods of the Service interface in the DDR Simple API whose signatures are:

- PropertyName newPropertyName(...) throws NameException
- PropertyRef newPropertyRef(...) throws NameException
- PropertyValues getPropertyValues(...) throws NameException
- PropertyValue getPropertyValue(...) throws NameException

The referenced compilable Java archive deviates from the specification in that one of the forms of the getPropertyValues method does not declare that it may throw a NameException.

On the basis of the pre-eminence of the normative specification, coupled with the statement in the specification that reads "The DDR Simple API is available as a JAR file, and as Javadoc", the appropriate course of action is to correct the deviation by repairing the Java archive.

It is regrettable that this inconsistency was not noted during the LC period, but it is also fortunate that this did not affect the function of implementations that were demonstrated in support of the viability of the API. This good fortune arises because the method form in question is the only one which would not actually throw an exception in an actual implementation, even though the API permits it to do so.

I further regret that this correction may require those who have been working on Java implementations, in cooperation with the DDWG, to change a line of code. This only affects those who used the attached Java file rather than the normative specification itself. Nevertheless, for the inconvenience, I apologise.

Finally, I acknowledge that there is an argument for having polymorphic methods with differing outcomes, including the exceptions they may throw. The argument, while interesting, is academic. In the DDR Simple API agreed by the group, and as presented for possible Recommendation by W3C, all of the polymorphic methods have consistent outcomes. I believe this is in the spirit of "Simple", and I can say that in some non-Java languages this is beneficial. No doubt this will be something to consider in future evolutions of the API, and of any "advanced" successors.

Again, I apologise whole-heartedly for any inconvenience.

---Rotan. (Chair)

-----Original Message-----
From: public-ddwg-request@... [mailto:public-ddwg-request@...] On Behalf Of Rotan Hanrahan
Sent: 12 August 2008 18:02
To: JOSE MANUEL CANTERA FONSECA; public-ddwg@...
Subject: RE: [API] Mistake on section 4.3.2.1

Thanks José,

However...

It will be observed that all of the polymorphic methods in the API differ only in their input parameters. This means the methods return the same data type and are capable of raising the same exceptions.

In the unique case of getPropertyValues(Evidence) this particular form of the polymorphic getPropertyValues method is technically permitted to raise the NameException but there are no circumstances in which doing so would be appropriate. However, to maintain the harmony with the rest of its siblings in the polymorphic set, it seems OK to leave it with the "throws NameException" signature.

A "fix" is unnecessary, assuming the design concept of polymorphism based solely on the input signature is accepted. But as this is a unique and unusual situation, it may be advised to document it in the implementation experience pages of the wiki. (This would also have the added benefit of avoiding any Process issues that would threaten to delay the specification.)

---Rotan.

________________________________

From: public-ddwg-request@... on behalf of JOSE MANUEL CANTERA FONSECA
Sent: Tue 12/08/2008 08:53
To: public-ddwg@...
Subject: [API] Mistake on section 4.3.2.1

Hi,

On the current editor's draft there is a mistake [1] :

public PropertyValues getPropertyValues(Evidence evidence)

throws NameException;

getPropertyValues should not raise NameException as it retrieves all known properties in all vocabularies.

If would be good if it could be fixed before the PR publication

Best Regards

[1] http://www.w3.org/2005/MWI/DDWG/drafts/api/080602#sec-Service-getPropertyValues-1

RE: [API] Mistake on section 4.3.2.1

2008-08-12T10:01:48Z

Thanks José,

However...

It will be observed that all of the polymorphic methods in the API differ only in their input parameters. This means the methods return the same data type and are capable of raising the same exceptions.

In the unique case of getPropertyValues(Evidence) this particular form of the polymorphic getPropertyValues method is technically permitted to raise the NameException but there are no circumstances in which doing so would be appropriate. However, to maintain the harmony with the rest of its siblings in the polymorphic set, it seems OK to leave it with the "throws NameException" signature.

A "fix" is unnecessary, assuming the design concept of polymorphism based solely on the input signature is accepted. But as this is a unique and unusual situation, it may be advised to document it in the implementation experience pages of the wiki. (This would also have the added benefit of avoiding any Process issues that would threaten to delay the specification.)

---Rotan.

________________________________

From: public-ddwg-request@... on behalf of JOSE MANUEL CANTERA FONSECA
Sent: Tue 12/08/2008 08:53
To: public-ddwg@...
Subject: [API] Mistake on section 4.3.2.1

Hi,

On the current editor's draft there is a mistake [1] :

public PropertyValues getPropertyValues(Evidence evidence)

throws NameException;

getPropertyValues should not raise NameException as it retrieves all known properties in all vocabularies.

If would be good if it could be fixed before the PR publication

Best Regards

[1] http://www.w3.org/2005/MWI/DDWG/drafts/api/080602#sec-Service-getPropertyValues-1

[API] Mistake on section 4.3.2.1

2008-08-12T00:53:27Z

Hi,

On the current editor's draft there is a mistake [1] :

public PropertyValues getPropertyValues(Evidence evidence)

throws NameException;

getPropertyValues should not raise NameException as it retrieves all known properties in all vocabularies.

If would be good if it could be fixed before the PR publication

Best Regards

[1] http://www.w3.org/2005/MWI/DDWG/drafts/api/080602#sec-Service-getPropertyValues-1

Perl implementation of DDR Simple API

2008-07-18T10:12:20Z

Perl implementation of DDR Simple API

I have uploaded a working draft [1] and highlighted version [2] of a Perl implementation of the final DDR Simple API.

The purpose of this code is to illustrate the API implemented in another of the programming languages that the DDWG identified as a target for the API. The implementation is in a single file, although the file itself represents several packages. It should execute on current Perl systems. The expected output is given in comments at the end of the source code.

The program contains some usage demonstrations, some convenience wrappers around the standard API methods, and a set of API tests derived from the previously presented Java test class.

The repository itself is also in the source code, in the form of a Perl data structure and a set of access methods. In a deployed implementation, one can expect that the actual repository would be an external database or some other such dedicated system, for reasons of performance, management, security etc. However, the program that I have now delivered is entirely in Perl and thus can be examined in isolation.

The implementation claims to support the DDR Core Vocabulary, but in reality I have only coded 11 of the properties, and provided data for a handful of imaginary devices. This is sufficient to illustrate the purpose of the API. There is no benefit from filling in more data.

I will not be working on this code for at least another month, so I have delivered it for your consideration in its current state, without any guarantees. It appears to be functioning as expected.

---Rotan.

[1] http://www.w3.org/2005/MWI/DDWG/drafts/api/simple/perl/ddrapi-perl-080718.pl

[2] http://www.w3.org/2005/MWI/DDWG/drafts/api/simple/perl/ddrapi-perl-080718.pdf

DDR Simple API implemented successfully

2008-06-24T03:55:45Z

DDR Simple API implemented successfully

As blogged [1], the DDR Simple API has been demonstrated to be viable. A number of demonstrations were discussed at last week’s Face-to-Face meeting of the group, held in France. This is an important milestone.

Implementers indicated that similar architectural approaches were used, particularly the use of mappings from standard vocabularies to proprietary vocabularies. The complexity of implementation is quite low, and a compliant implementation is easy to use in practice. Follow the link below to the implementation report and then to some of the implementation details.

The group will publish details of a C# implementation soon. We will also publish an early draft of a possible way to represent Structures (categories, groups, etc.), which will be a possible starting point for another working group to pick up from the DDWG.

Meanwhile, the DDWG has decided that the work on the deliverables listed in its charter has come to an end, so apart from the “paperwork”, the group will suspending activities. However, some of the participants have expressed a wish to continue providing some assistance to potential implementers, so we can expect some more material to appear on the wiki over the coming months.

Regards,

---Rotan (chair)

[1] http://www.w3.org/blog/DDWG/2008/06/24/ddr_simple_api_implemented_successfully

RE: Structures Editor's Draft

2008-06-22T11:55:13Z

For the benefit of others interested in this work, please note that we plan at this stage to publish this as a WG draft, but evolution of this work will be directed to elsewhere within W3C.

Merging of XML files into a single representation is a well-understood mechanism. A future update of this work might consider documenting such merger, and/or provide other means for processing multiple inputs.

In the DDR Simple API, when an aspect is expected but not given, then the "null" aspect is assumed. This provides support for vocabularies based on representations where support for aspects had not been anticipated. I assume that in the case of Structures, the optional nature of aspects is for the same reasons, and is handled in the same manner.

Uniqueness of IDs is important, yes. The scope of the uniqueness is something that should be considered in future.

The case-sensitivity should be documented to avoid misunderstanding. In general, IDs represented as Strings should be taken as literals, such that case is significant. Apart from efficiency, it avoids certain locale/culture issues where case mapping is not so simple. (Consider the Turkish language, for example.)

---Rotan

PS We generally don't modify the content of attachments, even if there's a typo in someone's name, but rest assured that we will verify spellings when we give this document a more permanent location.

-----Original Message-----
From: public-ddwg-request@... [mailto:public-ddwg-request@...] On Behalf Of Andrea Trasatti
Sent: 21 June 2008 08:11
To: JOSE MANUEL CANTERA FONSECA
Cc: public-ddwg@...
Subject: Re: Structures Editor's Draft

Hi José,
thank you for the reference to me in the document. My last name is
"Trasatti", of course, 1 s, 2 t's. :)

Chapter 3.1 says that the user should pass the XML to the API. There
is no definition of how to do that. Also, why limit to only 1 file? I
imagine developers defining different grouping rules in separate
files and then using some of the rules at run-time depending on the
local needs. An array should be supported.

I see that you defined the possibility to specify the aspect, but
wouldn't this be a required parameter when defining the groups?

Group ID's should be unique, I don't think you specified it in the
document.
Group ID's seem to be case sensitive from the way you built your
examples.

- Andrea

Il giorno 19/giu/08, alle ore 14:48, JOSE MANUEL CANTERA FONSECA ha
scritto:

> <structures.html>

Re: Structures Editor's Draft

2008-06-21T00:11:27Z

Hi José,
thank you for the reference to me in the document. My last name is
"Trasatti", of course, 1 s, 2 t's. :)

Chapter 3.1 says that the user should pass the XML to the API. There
is no definition of how to do that. Also, why limit to only 1 file? I
imagine developers defining different grouping rules in separate
files and then using some of the rules at run-time depending on the
local needs. An array should be supported.

I see that you defined the possibility to specify the aspect, but
wouldn't this be a required parameter when defining the groups?

Group ID's should be unique, I don't think you specified it in the
document.
Group ID's seem to be case sensitive from the way you built your
examples.

- Andrea

Il giorno 19/giu/08, alle ore 14:48, JOSE MANUEL CANTERA FONSECA ha
scritto:

> <structures.html>

Structures Editor's Draft

2008-06-19T05:48:32Z

Device Description Repository 1c

Exploiting Groups of Devices for Content Adaptation

Editors' Draft 16 June 2008

This version:: http://www.w3.org/2005/MWI/DDWG/drafts/structures/080616
Latest version:: http://www.w3.org/2005/MWI/DDWG/drafts/structures/latest
Previous version:: http://www.w3.org/2005/MWI/DDWG/drafts/api/080501
Editor:: JosÃ© Manuel Cantera Fonseca, TelefÃ³nica I+D

Abstract

Content Adaptation on the Mobile Web can be simplified by creating groups for those devices that share common characteristics. This WG Note defines an XML format, a group definition syntax and an extension to the DDR Simple API that can be used in the development of adaptive Mobile Web sites that exploit grouping.

Status of this Document

This document is an editors' copy that has no official standing.

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is an Editorial Draft of a possible future W3C Note

Publication as an Editorial Draft does not imply endorsement by the Device Description Working Group or the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document is published as part of the W3C Mobile Web Initiative (MWI) by the Device Description Working Group. It is a deliverable as defined in the Charter of that group.

Please send comments to public-ddwg@.... This list is archived at http://lists.w3.org/Archives/Public/public-ddwg-comments/.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Revision Description

1 Introduction
2 Device Grouping based on XML
Â Â Â Â 2.1 The deviceStructures element
Â Â Â Â 2.2 The vocabularies element
Â Â Â Â 2.3 The vocabulary element
Â Â Â Â Â Â Â Â 2.3.1 Attributes
Â Â Â Â 2.4 The groups element
Â Â Â Â 2.5 The group element
Â Â Â Â Â Â Â Â 2.5.1 Attributes
Â Â Â Â 2.6 The expression element
Â Â Â Â Â Â Â Â 2.6.1 Expression Syntax
3 Extended Simple API
Â Â Â Â 3.1 Initialization
Â Â Â Â 3.2 Query Methods
4 Example
Â Â Â Â 4.1 XML group definitions file
Â Â Â Â 4.2 Java Code

Appendices

A References
B Acknowledgements

1 Introduction

The mobile handset market is innovative and dynamic but at the same time fragmented. The result is that there are thousands of different devices made by multiple manufacturers. Nonetheless the majority of handsets share common characteristics and can be grouped into families. For example, all the devices made by a manufacturer or all the devices that provide certain functionalities. Device Grouping is useful as it provides a higher level of abstraction (in an specific context), avoiding to work with specific device instances or models.

Device Grouping is also a valuable tool for content adaptation on the Mobile Web. One significative example could be the dynamic generation of a web page that includes a game download menu. The version of each game to be offered to the user could depend on the manufacturer and memory restrictions imposed by the target device, among others. This particular application would benefit from the existence of a grouping mechanism. The developer could define different groups of devices specifying certain conditions to be met by the 'vendor' and 'availableMemory' property values.

Our problem could also have been solved by means of 'if' statements in any programming language (using the DDR Simple API). However such approach is unflexible as a change in the Group conditions would also imply a change in the application logic. Furthermore, "harcoded" Groups defined using programming language statements do not promote knowledge reuse between companies and organizations.

In order to promote a more flexible approach for Device Grouping, this W3C Note proposes an XML format, a syntax for group expressions (based on boolean conditions over the DDR properties) and an extension to the DDR Simple API.

2 Device Grouping based on XML

The device groups are defined in the XML format defined in the following sections. The XML infoset is described in XML Schema ... with each element in the http://www.w3.org/2008/05/structures namespace.

Element	Attributes	Minimal Content Model
deviceStructures	None	(vocabularies)?, groups
vocabularies	None	(vocabulary)+
vocabulary	iri, nsPrefix	EMPTY
groups	None	group+
group	id	expression
expression	None	PCDATA (See syntax)

2.1 The `deviceStructures` element

It is the element that serves as root of the XML document

2.2 The `vocabularies` element

This element is the parent element for all the vocabulary declarations in the XML document.

2.3 The `vocabulary` element

The purpose of this element is the declaration of the vocabularies that will be used in the group definitions.

2.3.1 Attributes

iri: The IRI of the vocabulary referenced. This attribute is mandatory.
nsPrefix: The namespace prefix assigned to the vocabulary. It will be used to reference qualified Property and Aspect names in expressions. This attribute is mandatory and there cannot be two vocabularies with the same prefix. Note that a vocabulary can be assigned the empty string as "" prefix, indicating that it will be the vocabulary used when properties are not fully qualified in expressions.

2.4 The `groups` element

This element is the parent element for all the groups defined

2.5 The `group` element

This is the element used to define a group of devices

2.5.1 Attributes

id: The group's id. This attribute is mandatory. This is the identifier that will be used later by the programmer in the code to ckeck if a device belongs to such group.

2.6 The `expression` element

This element includes the boolean expression that defines a group.

2.6.1 Expression Syntax

Boolean expressions can be used to denote the conditions that a device and its aspects must satisfy in order to belong to an specific group. The formal syntax for those expressions is (in simple Extended Backus-Naur Form (EBNF) notation):

Grammar for group expressions

[1]Â Â Â	`GroupExpr`	Â Â Â ::=Â Â Â	`'not' GroupExpr`
			`\| '(' GroupExpr ')'`
			`\| GroupExpr 'or' GroupExpr`
			`\| GroupExpr 'and' GroupExpr`
			`\| RelationalExpr`
[2]Â Â Â	`RelationalExpr`	Â Â Â ::=Â Â Â	`PropertyDef '>' Number`
			`\| PropertyDef '>=' Number`
			`\| PropertyDef '<' Number`
			`\| PropertyDef '<=' Number`
			`\| PropertyDef '==' Number \| Literal \| Boolean`
			`\| PropertyDef '!=' Number \| Literal \| Boolean`
			`\| PropertyDef 'contains' NumberEnum`
			`\| PropertyDef 'contains' LiteralEnum`
[3]Â Â Â	`PropertyDef`	Â Â Â ::=Â Â Â	`'[' PropertyNameDef ']'`
			`\| '[' PropertyNameDef ',' AspectNameDef ']'`
[4]Â Â Â	`PropertyNameDef`	Â Â Â ::=Â Â Â	`NsPrefix':'LocalPropertyName`
			`\| LocalPropertyName`
[5]Â Â Â	`AspectNameDef`	Â Â Â ::=Â Â Â	`NsPrefix':'LocalAspectName`
			`\| LocalAspectName`
[6]Â Â Â	`LocalPropertyName`	Â Â Â ::=Â Â Â	`NCName`
[7]Â Â Â	`LocalAspectName`	Â Â Â ::=Â Â Â	`NCName`
[8]Â Â Â	`NsPrefix`	Â Â Â ::=Â Â Â	`NCName`
[9]Â Â Â	`NumberEnum`	Â Â Â ::=Â Â Â	`(' ( Number ( ',' Number )* )? ')'`
[10]Â Â Â	`LiteralEnum`	Â Â Â ::=Â Â Â	`'(' ( Literal ( ',' Literal )* )? ')'`
[11]Â Â Â	`Literal`	Â Â Â ::=Â Â Â	`'"' [^"]* '"'`
			`\| "'" [^']* "'"`
[12]Â Â Â	`Boolean`	Â Â Â ::=Â Â Â	`'true'`
			`\| 'false'`
[13]Â Â Â	`Number`	Â Â Â ::=Â Â Â	`Digits ('.' Digits?)?`
			`\| '.' Digits`
[14]Â Â Â	`Digits`	Â Â Â ::=Â Â Â	`[0-9]+`

The semantics of the boolean operators used are the same as those present in programming languages like Java. The 'contains' clause returns true if the corresponding enumerated property value includes at least the set of elements between brackets.

3 Extended Simple API

This note proposes two extensions to the DDR Simple API

3.1 Initialization

At initialization time the user of the API need to pass the XML file with the group definitions to be used. This can be used passing the XML file as an additional initialization property.

3.2 Query Methods

public boolean belongsTo(Evidence evidence,String group);

Returns true if a device belongs to a group

4 Example

4.1 XML group definitions file

					
<deviceStructures xmlns="http://www.w3.org/2008/05/structures">
	<vocabularies>
		<vocabulary iri="http://www.w3.org/2008/01/ddr-core-vocabulary" nsPrefix="" />
		<vocabulary iri="http://example.org/vocabulary" nsPrefix="ex"/>
	</vocabularies>
	
	<groups>	
		<group id="NiceDevice">
			<expression>
				([imageFormatSupport,webBrowser] contains ('gif','jpeg') and [displayWidth] >= 240)
				or [ex:rendersTables,ex:webBrowser] == true and [inputDevices] contains ('touchScreen'))
			</expression>
		</group>
			
		<group id="XhtmlDevice">
			<expression>
				[markupSupport] contains ('xhtmlmp10','xhtmlbasic10')
			</expression>
		</group>		
	</groups>
</deviceStructures>

4.2 Java Code

Properties props = new Properties();
props.put("org.w3c.ddr.structures","file:///structuresExample.xml");
ServiceExt service = (ServiceExt)ServiceFactory.newService(
	"org.example.DDRServiceExt","http://www.w3.org/2008/01/ddr-core-vocabulary",props);

Evidence evidence = service.newHttpEvidence();
evidence.put("User-Agent","Example Browser 1.1 on Example Device");						
if(service.belongsTo(evidence,"XhtmlDevice")) {
	// Do Something
}
else {
		// Do other
}

A References

DDR-Simple-API: Device Description Repository Simple API, Jo Rabin, JosÃ© Manuel Cantera Fonseca, Rotan Hanrahan, Ignacio MarÃn (eds.), W3C Working Draft, 4 April 2008 (See http://www.w3.org/TR/DDR-Simple-API)
DDWG: DDWG Home Page (See http://www.w3.org/2005/MWI/DDWG/)
DIGLOSS: Glossary of Terms for Device Independence, W3C Working Draft, Rhys Lewis (ed.), 18 January 2005 (See http://www.w3.org/TR/2005/WD-di-gloss-20050118)
Core Vocabulary: Device Description Repository Core Vocabulary, W3C Working Draft, Andrea Trasatti, Jo Rabin, Rotan Hanrahan (eds.), 18 December 2007 (See http://www.w3.org/TR/ddr-core-vocabulary/)
Requirements: Device Description Repository Requirements 1.0, W3C Working Group Note, Kevin Smith (ed.), 17 December 2007 (See http://www.w3.org/TR/DDR-requirements/)
Landscape: Device Description Landscape 1.0, W3C Working Group Note, Eman Nkeze, James Pearce, Matt Womer (eds.), 31 October 2007, (See http://www.w3.org/TR/2007/NOTE-dd-landscape-20071031/)
Ecosystem: Device Description Ecosystem 1.0, W3C Working Group Note, Rotan Hanrahan (ed.), 31 October 2007 (See http://www.w3.org/TR/2007/NOTE-dd-ecosystem-20071031/)
Delivery Context Ontology: Delivery Context Ontology, W3C Working Draft, Rhys Lewis, JosÃ© Manuel Cantera Fonseca (eds.), 15 April 2008 (See http://www.w3.org/TR/dcontology/)
Java: The Java Language Specification, Third Edition (See http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html)
XML Namespaces: Namespaces in XML Second Edition, W3C Recommendation, Tim Bray, Dave Hollander, Andrew Layman Richard Tobin (eds.), 16 August 2006 (See http://www.w3.org/TR/2006/REC-xml-names-20060816/)

B Acknowledgements

The editor of the document acknowledge significant written contributions coming from:

Andrea Trassati, mTLD dotMobi

Updated DDR Simple API test class

2008-06-14T18:42:35Z

Following feedback, I now provide [1] an updated test class for the DDR
Simple API (for Java implementations) that takes a set of parameters to
tailor the test according to a preferred vocabulary, several test
properties and corresponding values. This will permit implementations to
use this test class with any vocabulary (including the DDR Core
Vocabulary) and with values for device descriptions that correspond to
actual or "invented" devices.

The test requires that the chosen vocabulary supports at least one of
each of the following types of value: Boolean, Enumeration, Integer and
String. I have not included tests for Double/Float/Long at this time,
though I note that a test that relied solely on the Core Vocabulary
could not pass the tests if these Real types were included because these
types are not used by the Core. (Feel free to extend the tests to cover
Reals if you wish.)

I must also re-iterate that this test has no normative status with
respect to the DDR Simple API, and the source might still be updated by
the group. Its sole purpose is to provide a common
implementation-neutral test of implementations that are based on the API
specification language (Java), which the presenters of such
implementations may use to support their claims of conformance to the
API specification.

I must also emphasise that while the test gives reasonable coverage of
functionality, it is not a complete test of an implementation, states
nothing about the performance of such an implementation nor makes any
claim regarding the quality of the data being queried via the API. Such
characteristics of an implementation are out of scope for the API.

Instantiation parameters are detailed in the embedded Javadoc.

The following code snippet shows how to invoke and report the test:
java.util.Hashtable report = (new DDRSimpleAPITester(
s, e,
"http://www.w3.org/TR/ddr-core-vocabulary/","webBrowser",
"device", 123,
"vendor", "model", "device", "device", "Acme Co.",
"displayWidth", "device", 120,
"cookieSupport", "webBrowser", true,
"markupSupport", "webBrowser", new String[]
{"xhtmlBasic10","xhtmlMP10"}
)).getReport();
Enumeration<Object> en = report.keys();
List keyList = Collections.list(en);
Collections.sort(keyList);
Enumeration sorted = Collections.enumeration(keyList);
while (sorted.hasMoreElements()) {
String k = (String)sorted.nextElement();
System.out.println((String)report.get(k)+ " " + k);
}

A successful test will produce the following report*.

Pass #sec-Evidence
Pass #sec-Evidence-exists
Pass #sec-Evidence-get
Pass #sec-Evidence-put
Pass #sec-PropertyName
Pass #sec-PropertyName-getLocalPropertyName
Pass #sec-PropertyName-getNamespace
Pass #sec-PropertyRef
Pass #sec-PropertyRef-getAspectName
Pass #sec-PropertyRef-getLocalPropertyName
Pass #sec-PropertyRef-getNamespace
Pass #sec-PropertyValue
Pass #sec-PropertyValue-exists
Pass #sec-PropertyValue-getPropertyRef
Pass #sec-PropertyValue-getXXX Boolean
???? #sec-PropertyValue-getXXX Double
Pass #sec-PropertyValue-getXXX Enumeration
???? #sec-PropertyValue-getXXX Float
Pass #sec-PropertyValue-getXXX Integer
???? #sec-PropertyValue-getXXX Long
Pass #sec-PropertyValue-getXXX String
Pass #sec-PropertyValues
Pass #sec-PropertyValues-getAll
Pass #sec-PropertyValues-getValue
Pass #sec-Service
Pass #sec-Service-getDataVersion
Pass #sec-Service-getImplementationVersion
Pass #sec-Service-getPropertyValue-1
Pass #sec-Service-getPropertyValue-2
Pass #sec-Service-getPropertyValue-3
Pass #sec-Service-getPropertyValue-4
Pass #sec-Service-getPropertyValues-1
Pass #sec-Service-getPropertyValues-2
Pass #sec-Service-getPropertyValues-3
Pass #sec-Service-getPropertyValues-4
Pass #sec-Service-initialize
Pass #sec-Service-listPropertyRefs
Pass #sec-Service-newHTTPEvidence-1
Pass #sec-Service-newHTTPEvidence-2
Pass #sec-Service-newPropertyName-1
Pass #sec-Service-newPropertyName-2
Pass #sec-Service-newPropertyRef-1
Pass #sec-Service-newPropertyRef-2
Pass #sec-Service-newPropertyRef-3

* This is an actual test run.

---Rotan (chair)

[1]
http://www.w3.org/2005/MWI/DDWG/drafts/api/simple/java/src/test/DDRSimpl
eAPITester.java

RE: DDR Simple API test class - Draft 1

2008-06-11T15:06:28Z

The proposal to have an implementation supply its own particular recognised device as input to the test is a good one, and I shall take it on board. Ditto with the idea of letting the implementation decide which vocabularies it will use. All of this is easy to parameterise.

The tests have no formal status within the process of taking the API to Rec, at this point in time. The group has resolved to accept three claims of conformance as sufficient to make progress out of CR. However, on advice received from informal dialogue with W3C team, being able to offer a more robust independent support of such claims may be requested. It is not a requirement at this point in time, nor is it certain that it will be a requirement, but in anticipation of the possibility I am trying to be prepared. While the "chapter and verse" of the W3C process may come into play here, there are also people in that process who are gatekeepers of transitions and their opinions are part of the process for very good reasons. I am considering all of the hurdles between here and Rec and intend to be as prepared as possible for each, be they chapter, verse or people.

---Rotan

________________________________

From: Jo Rabin [mailto:jrabin@...]
Sent: Wed 11/06/2008 16:51
To: Rotan Hanrahan
Cc: Ignacio Marin; public-ddwg@...
Subject: Re: DDR Simple API test class - Draft 1

Hi

I guess I didn't make my point clear, for which, apologies. What I am
trying to avoid is that every conforming instance of the DDR API
recognises the self same device and returns the same value for it. That
is not an aspect of API conformance as you said earlier (it would be a
test of the detection algorithm and the quality of the underlying
database, more than anything else).

So what I am suggesting is that each claim of conformance is free to
choose its own "known good device".

The idea of using the DDC goes against this in the respect that
implementations should be free to have whatever devices they like and
exclude whatever devices they like. But if we _were_ to have a single
device then that would be the one I choose, because it is a vendor
neutral choice, and because there are things you can say about it, by
definition. It does no harm for DDRs to know about it, since
increasingly we hope that authors will test their site for mobileOK ness
and recognising the DDR is usually part of conformance for mobileOK.

I do take issue with the idea that the test suite tests for elements of
the core vocabulary. As implementations are not required to support it.
DeviceAtlas does, as it happens, but that is not the point.

I'm also unsure what the status of a pass or a fail from the checker is
in respect of a claim to conform to the API. Are you required to have
run the checker? If so, at what revision? etc. etc. etc. I'm wondering
what the chapter and verse of W3C process is that mandates this and for
what purpose? (The reason for asking is that I am worried that the
conformance section of the document may have to change, or if it doesn't
then why do we have to have a checker - since it is not normatively
referred to anywhere?)

Cheers
Jo

On 11/06/2008 13:42, Rotan Hanrahan wrote:

> The only problem with a "UA known to be recognised" is that I didn't want to create any perception of favouritism towards any device manufacturer, and I wanted the test to be completely under our control.
>
> The reason for having explicit "not known" values was to test the behaviour associated with values that are not known, though like you say, this could be done on the basis of not knowing anything at all about the device (i.e. the device is unrecognised).
>
> Using the DDC as a virtual device sounds like a nice idea, though there's no particular reason why these values would have any particular benefit over any other values. It's not like the DDC is going to have a role here, and I'd be wary of implying some role for the DDC in the DDR.
>
> If we do decide to go with some "UA known to be recognised", I'd like us to agree up front the values for the properties, and also to check with the vendors (of the device and the browser) so that we don't misrepresent their products, or otherwise we might have to deal with complaints and other distractions.
>
> I'll have another draft of the code tomorrow, probably, and I'll put it into the drafts space on the main server.
>
> ---Rotan
>
>
>
> -----Original Message-----
> From: Jo Rabin [mailto:jrabin@...]
> Sent: 11 June 2008 10:51
> To: Ignacio Marin
> Cc: Rotan Hanrahan; public-ddwg@...
> Subject: Re: DDR Simple API test class - Draft 1
>
> Thanks Rotan.
>
> Ref the C# implementation, that would be nice, but not strictly a
> conformance test, I think.
>
> I'd be happier if the test did not depend on the insertion of a virtual
> device into a particular data set - although I could see the argument
> for testing against the DDC, possibly. I'd prefer that the positive
> tests were carried out on a "UA known to be recognised" and that the
> negative tests were carried out on a device "known not to be recognised"
> by a particular implementation. It being up to those claiming
> conformance to identify what those devices were ...
>
> ... I'm also a bit concerned that it is legitimate for an implementation
> "not to know" values. If I have understood the code correctly it's
> assumed that a value exists for these properties. I'm not especially
> suggesting that two devices are tested, one of which has known values
> and the other not, but I'm not sure I know what the alternative is.
>
> That would mean in detail that we tested 3 devices. One unrecognised,
> one known for which the values are know and one known for which the
> values are not known ...
>
> Jo
>
> On 11/06/2008 08:27, Ignacio Marin wrote:
>> Once that the group agrees on the definition of these Java tests, I
>> think it would be an easy task to port them to C#.
>>
>> So C# can be counted in the set of technologies for which the test suite
>> will be available.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Nacho
>>
>>
>>
>> ******************************************
>>
>> Ignacio Marín Prendes
>>
>> Head of Unit of Device Independence and Mobility
>>
>> R&D Department
>>
>> ignacio.marin@...
>> <blocked::BLOCKED::mailto:ignacio.marin@...>
>>
>> www.fundacionctic.org
>> <blocked::BLOCKED::blocked::http://www.fundacionctic.org <http://www.fundacionctic.org/> >
>>
>> Fundación CTIC -Centro Tecnológico de la Información y la Comunicación-
>>
>> Parque Científico y Tecnológico de Gijón
>>
>> Edificio Centros Tecnológicos
>>
>> 33203 Cabueñes - Gijón - Asturias
>>
>> Teléfono: 984 29 12 12
>>
>> Fax: 984 39 06 12
>>
>> ******************************************
>>
>> Este e-mail y cualquiera de sus ficheros anexos son confidenciales y
>> pueden incluir información privilegiada. Si usted no es el destinatario
>> adecuado (o responsable de remitirlo a la persona indicada),
>> agradeceríamos lo notificase o reenviase inmediatamente al emisor. No
>> revele estos contenidos a ninguna otra persona, no los utilice para otra
>> finalidad, ni almacene y/o copie esta información en medio alguno.
>>
>> Opiniones, conclusiones y otro tipo de información relacionada con este
>> mensaje que no sean relativas a la actividad propia de CTIC deberán ser
>> entendidas como exclusivas del emisor.
>>
>> --------------------------------------------
>>
>> /This e-mail is confidential and may contain legally privileged
>> information. If you are not the intended recipient it may be unlawful
>> for you to read, copy, distribute or otherwise make use of the
>> information herein. If you have received this e-mail in error, please
>> contact us immediately. Fundación CTIC will accept no liability for the
>> mistransmission, interference, or interception of any e-mail and you are
>> reminded that e-mail is not a secure method of communication./
>>
>> ------------------------------------------------------------------------
>>
>> *De:* public-ddwg-request@... [mailto:public-ddwg-request@...] *En
>> nombre de *Rotan Hanrahan
>> *Enviado el:* miércoles, 11 de junio de 2008 5:01
>> *Para:* public-ddwg@...
>> *Asunto:* DDR Simple API test class - Draft 1
>>
>>
>>
>> Attached is a simple Java class that can be used to exercise the
>> majority of the methods in a compliant Java implementation of the
>> proposed DDR Simple API.
>>
>> I have written this first draft as a contribution to next week's
>> face-to-face meeting in France in which we expect to be informed of
>> multiple implementations. Code based on the draft I am submitting can be
>> used to verify that key use cases for a Java implementation are behaving
>> in conformance with the specification. Following the recent publication
>> of what the DDWG members believe is a stable and worthy specification,
>> there is now a keen interest in seeing implementations that claim to
>> conform to this specification, so that we can make progress towards a
>> formal Recommendation. Such claims can be put to the test with the aid
>> of the attached code.
>>
>> Note, this draft does not validate the error use cases, where exceptions
>> are defined in the specification. I expect this to be in an update.
>>
>> The test currently relies only on the Core Vocabulary, and to provide
>> the necessary predictability of the underlying data, a "virtual" device
>> is being considered, whose identity can be determined solely by the User
>> Agent header. For the purpose of the test, implementations should
>> recognise this virtual device, and their underlying data should be
>> populated with the expected values (as indicated by the constants
>> present in the test source).
>>
>> This is not an exhaustive test, nor a system test, nor a performance
>> test. It is not a test of the correctness of the underlying data. All
>> such tests would be out of scope for the API itself. The purpose of the
>> test suite captured in this draft class is to exercise the API in a
>> manner consistent with the expected use cases for implementations that
>> have heeded the suggestion to support the Core Vocabulary, in order to
>> raise confidence that, from a functional point of view, the
>> implementations conform to the specification. Multiple claims that are
>> so supported may be sufficient evidence of the viability of this new
>> technology.
>>
>> This contribution also anticipates a likely expectation from observers
>> that progress towards a formal Recommendation should be accompanied,
>> insofar as possible and practical, reasonable and independent support
>> for any claims of conformance.
>>
>> Finally, the tests are implemented in Java but the API is designed to be
>> language-neutral (as far as possible). Unfortunately time constraints
>> prevent me from providing similar tests in other languages, but
>> contributions would be welcome (after the tests have been agreed by the
>> group).
>>
>> ---Rotan (chair).
>>
>> <<DDRSimpleAPITester.java>>
>>
>

Re: DDR Simple API test class - Draft 1

2008-06-11T08:51:18Z

Hi

I guess I didn't make my point clear, for which, apologies. What I am
trying to avoid is that every conforming instance of the DDR API
recognises the self same device and returns the same value for it. That
is not an aspect of API conformance as you said earlier (it would be a
test of the detection algorithm and the quality of the underlying
database, more than anything else).

So what I am suggesting is that each claim of conformance is free to
choose its own "known good device".

The idea of using the DDC goes against this in the respect that
implementations should be free to have whatever devices they like and
exclude whatever devices they like. But if we _were_ to have a single
device then that would be the one I choose, because it is a vendor
neutral choice, and because there are things you can say about it, by
definition. It does no harm for DDRs to know about it, since
increasingly we hope that authors will test their site for mobileOK ness
and recognising the DDR is usually part of conformance for mobileOK.

I do take issue with the idea that the test suite tests for elements of
the core vocabulary. As implementations are not required to support it.
DeviceAtlas does, as it happens, but that is not the point.

I'm also unsure what the status of a pass or a fail from the checker is
in respect of a claim to conform to the API. Are you required to have
run the checker? If so, at what revision? etc. etc. etc. I'm wondering
what the chapter and verse of W3C process is that mandates this and for
what purpose? (The reason for asking is that I am worried that the
conformance section of the document may have to change, or if it doesn't
then why do we have to have a checker - since it is not normatively
referred to anywhere?)

Cheers
Jo

On 11/06/2008 13:42, Rotan Hanrahan wrote:

> The only problem with a "UA known to be recognised" is that I didn't want to create any perception of favouritism towards any device manufacturer, and I wanted the test to be completely under our control.
>
> The reason for having explicit "not known" values was to test the behaviour associated with values that are not known, though like you say, this could be done on the basis of not knowing anything at all about the device (i.e. the device is unrecognised).
>
> Using the DDC as a virtual device sounds like a nice idea, though there's no particular reason why these values would have any particular benefit over any other values. It's not like the DDC is going to have a role here, and I'd be wary of implying some role for the DDC in the DDR.
>
> If we do decide to go with some "UA known to be recognised", I'd like us to agree up front the values for the properties, and also to check with the vendors (of the device and the browser) so that we don't misrepresent their products, or otherwise we might have to deal with complaints and other distractions.
>
> I'll have another draft of the code tomorrow, probably, and I'll put it into the drafts space on the main server.
>
> ---Rotan
>
>
>
> -----Original Message-----
> From: Jo Rabin [mailto:jrabin@...]
> Sent: 11 June 2008 10:51
> To: Ignacio Marin
> Cc: Rotan Hanrahan; public-ddwg@...
> Subject: Re: DDR Simple API test class - Draft 1
>
> Thanks Rotan.
>
> Ref the C# implementation, that would be nice, but not strictly a
> conformance test, I think.
>
> I'd be happier if the test did not depend on the insertion of a virtual
> device into a particular data set - although I could see the argument
> for testing against the DDC, possibly. I'd prefer that the positive
> tests were carried out on a "UA known to be recognised" and that the
> negative tests were carried out on a device "known not to be recognised"
> by a particular implementation. It being up to those claiming
> conformance to identify what those devices were ...
>
> ... I'm also a bit concerned that it is legitimate for an implementation
> "not to know" values. If I have understood the code correctly it's
> assumed that a value exists for these properties. I'm not especially
> suggesting that two devices are tested, one of which has known values
> and the other not, but I'm not sure I know what the alternative is.
>
> That would mean in detail that we tested 3 devices. One unrecognised,
> one known for which the values are know and one known for which the
> values are not known ...
>
> Jo
>
> On 11/06/2008 08:27, Ignacio Marin wrote:
>> Once that the group agrees on the definition of these Java tests, I
>> think it would be an easy task to port them to C#.
>>
>> So C# can be counted in the set of technologies for which the test suite
>> will be available.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Nacho
>>
>>
>>
>> ******************************************
>>
>> Ignacio Marín Prendes
>>
>> Head of Unit of Device Independence and Mobility
>>
>> R&D Department
>>
>> ignacio.marin@...
>> <blocked::BLOCKED::mailto:ignacio.marin@...>
>>
>> www.fundacionctic.org
>> <blocked::BLOCKED::blocked::http://www.fundacionctic.org>
>>
>> Fundación CTIC -Centro Tecnológico de la Información y la Comunicación-
>>
>> Parque Científico y Tecnológico de Gijón
>>
>> Edificio Centros Tecnológicos
>>
>> 33203 Cabueñes - Gijón - Asturias
>>
>> Teléfono: 984 29 12 12
>>
>> Fax: 984 39 06 12
>>
>> ******************************************
>>
>> Este e-mail y cualquiera de sus ficheros anexos son confidenciales y
>> pueden incluir información privilegiada. Si usted no es el destinatario
>> adecuado (o responsable de remitirlo a la persona indicada),
>> agradeceríamos lo notificase o reenviase inmediatamente al emisor. No
>> revele estos contenidos a ninguna otra persona, no los utilice para otra
>> finalidad, ni almacene y/o copie esta información en medio alguno.
>>
>> Opiniones, conclusiones y otro tipo de información relacionada con este
>> mensaje que no sean relativas a la actividad propia de CTIC deberán ser
>> entendidas como exclusivas del emisor.
>>
>> --------------------------------------------
>>
>> /This e-mail is confidential and may contain legally privileged
>> information. If you are not the intended recipient it may be unlawful
>> for you to read, copy, distribute or otherwise make use of the
>> information herein. If you have received this e-mail in error, please
>> contact us immediately. Fundación CTIC will accept no liability for the
>> mistransmission, interference, or interception of any e-mail and you are
>> reminded that e-mail is not a secure method of communication./
>>
>> ------------------------------------------------------------------------
>>
>> *De:* public-ddwg-request@... [mailto:public-ddwg-request@...] *En
>> nombre de *Rotan Hanrahan
>> *Enviado el:* miércoles, 11 de junio de 2008 5:01
>> *Para:* public-ddwg@...
>> *Asunto:* DDR Simple API test class - Draft 1
>>
>>
>>
>> Attached is a simple Java class that can be used to exercise the
>> majority of the methods in a compliant Java implementation of the
>> proposed DDR Simple API.
>>
>> I have written this first draft as a contribution to next week's
>> face-to-face meeting in France in which we expect to be informed of
>> multiple implementations. Code based on the draft I am submitting can be
>> used to verify that key use cases for a Java implementation are behaving
>> in conformance with the specification. Following the recent publication
>> of what the DDWG members believe is a stable and worthy specification,
>> there is now a keen interest in seeing implementations that claim to
>> conform to this specification, so that we can make progress towards a
>> formal Recommendation. Such claims can be put to the test with the aid
>> of the attached code.
>>
>> Note, this draft does not validate the error use cases, where exceptions
>> are defined in the specification. I expect this to be in an update.
>>
>> The test currently relies only on the Core Vocabulary, and to provide
>> the necessary predictability of the underlying data, a "virtual" device
>> is being considered, whose identity can be determined solely by the User
>> Agent header. For the purpose of the test, implementations should
>> recognise this virtual device, and their underlying data should be
>> populated with the expected values (as indicated by the constants
>> present in the test source).
>>
>> This is not an exhaustive test, nor a system test, nor a performance
>> test. It is not a test of the correctness of the underlying data. All
>> such tests would be out of scope for the API itself. The purpose of the
>> test suite captured in this draft class is to exercise the API in a
>> manner consistent with the expected use cases for implementations that
>> have heeded the suggestion to support the Core Vocabulary, in order to
>> raise confidence that, from a functional point of view, the
>> implementations conform to the specification. Multiple claims that are
>> so supported may be sufficient evidence of the viability of this new
>> technology.
>>
>> This contribution also anticipates a likely expectation from observers
>> that progress towards a formal Recommendation should be accompanied,
>> insofar as possible and practical, reasonable and independent support
>> for any claims of conformance.
>>
>> Finally, the tests are implemented in Java but the API is designed to be
>> language-neutral (as far as possible). Unfortunately time constraints
>> prevent me from providing similar tests in other languages, but
>> contributions would be welcome (after the tests have been agreed by the
>> group).
>>
>> ---Rotan (chair).
>>
>> <<DDRSimpleAPITester.java>>
>>
>

RE: DDR Simple API test class - Draft 1

2008-06-11T05:42:04Z

The only problem with a "UA known to be recognised" is that I didn't want to create any perception of favouritism towards any device manufacturer, and I wanted the test to be completely under our control.

The reason for having explicit "not known" values was to test the behaviour associated with values that are not known, though like you say, this could be done on the basis of not knowing anything at all about the device (i.e. the device is unrecognised).

Using the DDC as a virtual device sounds like a nice idea, though there's no particular reason why these values would have any particular benefit over any other values. It's not like the DDC is going to have a role here, and I'd be wary of implying some role for the DDC in the DDR.

If we do decide to go with some "UA known to be recognised", I'd like us to agree up front the values for the properties, and also to check with the vendors (of the device and the browser) so that we don't misrepresent their products, or otherwise we might have to deal with complaints and other distractions.

I'll have another draft of the code tomorrow, probably, and I'll put it into the drafts space on the main server.

---Rotan

-----Original Message-----
From: Jo Rabin [mailto:jrabin@...]
Sent: 11 June 2008 10:51
To: Ignacio Marin
Cc: Rotan Hanrahan; public-ddwg@...
Subject: Re: DDR Simple API test class - Draft 1

Thanks Rotan.

Ref the C# implementation, that would be nice, but not strictly a
conformance test, I think.

I'd be happier if the test did not depend on the insertion of a virtual
device into a particular data set - although I could see the argument
for testing against the DDC, possibly. I'd prefer that the positive
tests were carried out on a "UA known to be recognised" and that the
negative tests were carried out on a device "known not to be recognised"
by a particular implementation. It being up to those claiming
conformance to identify what those devices were ...

... I'm also a bit concerned that it is legitimate for an implementation
"not to know" values. If I have understood the code correctly it's
assumed that a value exists for these properties. I'm not especially
suggesting that two devices are tested, one of which has known values
and the other not, but I'm not sure I know what the alternative is.

That would mean in detail that we tested 3 devices. One unrecognised,
one known for which the values are know and one known for which the
values are not known ...

Jo

On 11/06/2008 08:27, Ignacio Marin wrote:

> Once that the group agrees on the definition of these Java tests, I
> think it would be an easy task to port them to C#.
>
> So C# can be counted in the set of technologies for which the test suite
> will be available.
>
>
>
> Regards,
>
>
>
> Nacho
>
>
>
> ******************************************
>
> Ignacio Marín Prendes
>
> Head of Unit of Device Independence and Mobility
>
> R&D Department
>
> ignacio.marin@...
> <blocked::BLOCKED::mailto:ignacio.marin@...>
>
> www.fundacionctic.org
> <blocked::BLOCKED::blocked::http://www.fundacionctic.org>
>
> Fundación CTIC -Centro Tecnológico de la Información y la Comunicación-
>
> Parque Científico y Tecnológico de Gijón
>
> Edificio Centros Tecnológicos
>
> 33203 Cabueñes - Gijón - Asturias
>
> Teléfono: 984 29 12 12
>
> Fax: 984 39 06 12
>
> ******************************************
>
> Este e-mail y cualquiera de sus ficheros anexos son confidenciales y
> pueden incluir información privilegiada. Si usted no es el destinatario
> adecuado (o responsable de remitirlo a la persona indicada),
> agradeceríamos lo notificase o reenviase inmediatamente al emisor. No
> revele estos contenidos a ninguna otra persona, no los utilice para otra
> finalidad, ni almacene y/o copie esta información en medio alguno.
>
> Opiniones, conclusiones y otro tipo de información relacionada con este
> mensaje que no sean relativas a la actividad propia de CTIC deberán ser
> entendidas como exclusivas del emisor.
>
> --------------------------------------------
>
> /This e-mail is confidential and may contain legally privileged
> information. If you are not the intended recipient it may be unlawful
> for you to read, copy, distribute or otherwise make use of the
> information herein. If you have received this e-mail in error, please
> contact us immediately. Fundación CTIC will accept no liability for the
> mistransmission, interference, or interception of any e-mail and you are
> reminded that e-mail is not a secure method of communication./
>
> ------------------------------------------------------------------------
>
> *De:* public-ddwg-request@... [mailto:public-ddwg-request@...] *En
> nombre de *Rotan Hanrahan
> *Enviado el:* miércoles, 11 de junio de 2008 5:01
> *Para:* public-ddwg@...
> *Asunto:* DDR Simple API test class - Draft 1
>
>
>
> Attached is a simple Java class that can be used to exercise the
> majority of the methods in a compliant Java implementation of the
> proposed DDR Simple API.
>
> I have written this first draft as a contribution to next week's
> face-to-face meeting in France in which we expect to be informed of
> multiple implementations. Code based on the draft I am submitting can be
> used to verify that key use cases for a Java implementation are behaving
> in conformance with the specification. Following the recent publication
> of what the DDWG members believe is a stable and worthy specification,
> there is now a keen interest in seeing implementations that claim to
> conform to this specification, so that we can make progress towards a
> formal Recommendation. Such claims can be put to the test with the aid
> of the attached code.
>
> Note, this draft does not validate the error use cases, where exceptions
> are defined in the specification. I expect this to be in an update.
>
> The test currently relies only on the Core Vocabulary, and to provide
> the necessary predictability of the underlying data, a "virtual" device
> is being considered, whose identity can be determined solely by the User
> Agent header. For the purpose of the test, implementations should
> recognise this virtual device, and their underlying data should be
> populated with the expected values (as indicated by the constants
> present in the test source).
>
> This is not an exhaustive test, nor a system test, nor a performance
> test. It is not a test of the correctness of the underlying data. All
> such tests would be out of scope for the API itself. The purpose of the
> test suite captured in this draft class is to exercise the API in a
> manner consistent with the expected use cases for implementations that
> have heeded the suggestion to support the Core Vocabulary, in order to
> raise confidence that, from a functional point of view, the
> implementations conform to the specification. Multiple claims that are
> so supported may be sufficient evidence of the viability of this new
> technology.
>
> This contribution also anticipates a likely expectation from observers
> that progress towards a formal Recommendation should be accompanied,
> insofar as possible and practical, reasonable and independent support
> for any claims of conformance.
>
> Finally, the tests are implemented in Java but the API is designed to be
> language-neutral (as far as possible). Unfortunately time constraints
> prevent me from providing similar tests in other languages, but
> contributions would be welcome (after the tests have been agreed by the
> group).
>
> ---Rotan (chair).
>
> <<DDRSimpleAPITester.java>>
>

RE: DDR Simple API test class - Draft 1

2008-06-11T05:32:27Z

DDR Simple API test class - Draft 1

Oops. :) Thanks José. I copied the wrong URL into the string.

---R

From: JOSE MANUEL CANTERA FONSECA [mailto:jmcf@...]
Sent: 11 June 2008 11:50
To: Rotan Hanrahan; public-ddwg@...
Subject: RE: DDR Simple API test class - Draft 1

There is a mistake in your code in the constant that declares what is the IRI of the core vocabulary, you are referring to the WG's Note but not the actually the IRI of the core vocabulary

De: public-ddwg-request@... [mailto:public-ddwg-request@...] En nombre de Rotan Hanrahan
Enviado el: miércoles, 11 de junio de 2008 5:01
Para: public-ddwg@...
Asunto: DDR Simple API test class - Draft 1

Attached is a simple Java class that can be used to exercise the majority of the methods in a compliant Java implementation of the proposed DDR Simple API.

I have written this first draft as a contribution to next week’s face-to-face meeting in France in which we expect to be informed of multiple implementations. Code based on the draft I am submitting can be used to verify that key use cases for a Java implementation are behaving in conformance with the specification. Following the recent publication of what the DDWG members believe is a stable and worthy specification, there is now a keen interest in seeing implementations that claim to conform to this specification, so that we can make progress towards a formal Recommendation. Such claims can be put to the test with the aid of the attached code.

Note, this draft does not validate the error use cases, where exceptions are defined in the specification. I expect this to be in an update.

The test currently relies only on the Core Vocabulary, and to provide the necessary predictability of the underlying data, a “virtual” device is being considered, whose identity can be determined solely by the User Agent header. For the purpose of the test, implementations should recognise this virtual device, and their underlying data should be populated with the expected values (as indicated by the constants present in the test source).

This is not an exhaustive test, nor a system test, nor a performance test. It is not a test of the correctness of the underlying data. All such tests would be out of scope for the API itself. The purpose of the test suite captured in this draft class is to exercise the API in a manner consistent with the expected use cases for implementations that have heeded the suggestion to support the Core Vocabulary, in order to raise confidence that, from a functional point of view, the implementations conform to the specification. Multiple claims that are so supported may be sufficient evidence of the viability of this new technology.

This contribution also anticipates a likely expectation from observers that progress towards a formal Recommendation should be accompanied, insofar as possible and practical, reasonable and independent support for any claims of conformance.

Finally, the tests are implemented in Java but the API is designed to be language-neutral (as far as possible). Unfortunately time constraints prevent me from providing similar tests in other languages, but contributions would be welcome (after the tests have been agreed by the group).

---Rotan (chair).

<<DDRSimpleAPITester.java>>

RE: DDR Simple API test class - Draft 1

2008-06-11T03:50:28Z

DDR Simple API test class - Draft 1

There is a mistake in your code in the constant that declares what is the IRI of the core vocabulary, you are referring to the WG's Note but not the actually the IRI of the core vocabulary

Attached is a simple Java class that can be used to exercise the majority of the methods in a compliant Java implementation of the proposed DDR Simple API.

Note, this draft does not validate the error use cases, where exceptions are defined in the specification. I expect this to be in an update.

---Rotan (chair).

<<DDRSimpleAPITester.java>>

Re: DDR Simple API test class - Draft 1

2008-06-11T02:50:53Z

Thanks Rotan.

Ref the C# implementation, that would be nice, but not strictly a
conformance test, I think.

I'd be happier if the test did not depend on the insertion of a virtual
device into a particular data set - although I could see the argument
for testing against the DDC, possibly. I'd prefer that the positive
tests were carried out on a "UA known to be recognised" and that the
negative tests were carried out on a device "known not to be recognised"
by a particular implementation. It being up to those claiming
conformance to identify what those devices were ...

... I'm also a bit concerned that it is legitimate for an implementation
"not to know" values. If I have understood the code correctly it's
assumed that a value exists for these properties. I'm not especially
suggesting that two devices are tested, one of which has known values
and the other not, but I'm not sure I know what the alternative is.

That would mean in detail that we tested 3 devices. One unrecognised,
one known for which the values are know and one known for which the
values are not known ...

Jo

On 11/06/2008 08:27, Ignacio Marin wrote:

> Once that the group agrees on the definition of these Java tests, I
> think it would be an easy task to port them to C#.
>
> So C# can be counted in the set of technologies for which the test suite
> will be available.
>
>
>
> Regards,
>
>
>
> Nacho
>
>
>
> ******************************************
>
> Ignacio Marín Prendes
>
> Head of Unit of Device Independence and Mobility
>
> R&D Department
>
> ignacio.marin@...
> <blocked::BLOCKED::mailto:ignacio.marin@...>
>
> www.fundacionctic.org
> <blocked::BLOCKED::blocked::http://www.fundacionctic.org>
>
> Fundación CTIC -Centro Tecnológico de la Información y la Comunicación-
>
> Parque Científico y Tecnológico de Gijón
>
> Edificio Centros Tecnológicos
>
> 33203 Cabueñes – Gijón – Asturias
>
> Teléfono: 984 29 12 12
>
> Fax: 984 39 06 12
>
> ******************************************
>
> Este e-mail y cualquiera de sus ficheros anexos son confidenciales y
> pueden incluir información privilegiada. Si usted no es el destinatario
> adecuado (o responsable de remitirlo a la persona indicada),
> agradeceríamos lo notificase o reenviase inmediatamente al emisor. No
> revele estos contenidos a ninguna otra persona, no los utilice para otra
> finalidad, ni almacene y/o copie esta información en medio alguno.
>
> Opiniones, conclusiones y otro tipo de información relacionada con este
> mensaje que no sean relativas a la actividad propia de CTIC deberán ser
> entendidas como exclusivas del emisor.
>
> --------------------------------------------
>
> /This e-mail is confidential and may contain legally privileged
> information. If you are not the intended recipient it may be unlawful
> for you to read, copy, distribute or otherwise make use of the
> information herein. If you have received this e-mail in error, please
> contact us immediately. Fundación CTIC will accept no liability for the
> mistransmission, interference, or interception of any e-mail and you are
> reminded that e-mail is not a secure method of communication./
>
> ------------------------------------------------------------------------
>
> *De:* public-ddwg-request@... [mailto:public-ddwg-request@...] *En
> nombre de *Rotan Hanrahan
> *Enviado el:* miércoles, 11 de junio de 2008 5:01
> *Para:* public-ddwg@...
> *Asunto:* DDR Simple API test class - Draft 1
>
>
>
> Attached is a simple Java class that can be used to exercise the
> majority of the methods in a compliant Java implementation of the
> proposed DDR Simple API.
>
> I have written this first draft as a contribution to next week’s
> face-to-face meeting in France in which we expect to be informed of
> multiple implementations. Code based on the draft I am submitting can be
> used to verify that key use cases for a Java implementation are behaving
> in conformance with the specification. Following the recent publication
> of what the DDWG members believe is a stable and worthy specification,
> there is now a keen interest in seeing implementations that claim to
> conform to this specification, so that we can make progress towards a
> formal Recommendation. Such claims can be put to the test with the aid
> of the attached code.
>
> Note, this draft does not validate the error use cases, where exceptions
> are defined in the specification. I expect this to be in an update.
>
> The test currently relies only on the Core Vocabulary, and to provide
> the necessary predictability of the underlying data, a “virtual” device
> is being considered, whose identity can be determined solely by the User
> Agent header. For the purpose of the test, implementations should
> recognise this virtual device, and their underlying data should be
> populated with the expected values (as indicated by the constants
> present in the test source).
>
> This is not an exhaustive test, nor a system test, nor a performance
> test. It is not a test of the correctness of the underlying data. All
> such tests would be out of scope for the API itself. The purpose of the
> test suite captured in this draft class is to exercise the API in a
> manner consistent with the expected use cases for implementations that
> have heeded the suggestion to support the Core Vocabulary, in order to
> raise confidence that, from a functional point of view, the
> implementations conform to the specification. Multiple claims that are
> so supported may be sufficient evidence of the viability of this new
> technology.
>
> This contribution also anticipates a likely expectation from observers
> that progress towards a formal Recommendation should be accompanied,
> insofar as possible and practical, reasonable and independent support
> for any claims of conformance.
>
> Finally, the tests are implemented in Java but the API is designed to be
> language-neutral (as far as possible). Unfortunately time constraints
> prevent me from providing similar tests in other languages, but
> contributions would be welcome (after the tests have been agreed by the
> group).
>
> ---Rotan (chair).
>
> <<DDRSimpleAPITester.java>>
>

RE: DDR Simple API test class - Draft 1

2008-06-11T00:27:32Z

DDR Simple API test class - Draft 1

Once that the group agrees on the definition of these Java tests, I think it would be an easy task to port them to C#.

So C# can be counted in the set of technologies for which the test suite will be available.

Regards,

Nacho

******************************************

Ignacio Marín Prendes

Head of Unit of Device Independence and Mobility

R&D Department

ignacio.marin@...

www.fundacionctic.org

Fundación CTIC -Centro Tecnológico de la Información y la Comunicación-

Parque Científico y Tecnológico de Gijón

Edificio Centros Tecnológicos

33203 Cabueñes – Gijón – Asturias

Teléfono: 984 29 12 12

Fax: 984 39 06 12

******************************************

Este e-mail y cualquiera de sus ficheros anexos son confidenciales y pueden incluir información privilegiada. Si usted no es el destinatario adecuado (o responsable de remitirlo a la persona indicada), agradeceríamos lo notificase o reenviase inmediatamente al emisor. No revele estos contenidos a ninguna otra persona, no los utilice para otra finalidad, ni almacene y/o copie esta información en medio alguno.

Opiniones, conclusiones y otro tipo de información relacionada con este mensaje que no sean relativas a la actividad propia de CTIC deberán ser entendidas como exclusivas del emisor.

--------------------------------------------

This e-mail is confidential and may contain legally privileged information. If you are not the intended recipient it may be unlawful for you to read, copy, distribute or otherwise make use of the information herein. If you have received this e-mail in error, please contact us immediately. Fundación CTIC will accept no liability for the mistransmission, interference, or interception of any e-mail and you are reminded that e-mail is not a secure method of communication.

Attached is a simple Java class that can be used to exercise the majority of the methods in a compliant Java implementation of the proposed DDR Simple API.

Note, this draft does not validate the error use cases, where exceptions are defined in the specification. I expect this to be in an update.

---Rotan (chair).

<<DDRSimpleAPITester.java>>

DDR Simple API test class - Draft 1

2008-06-10T20:01:01Z

DDR Simple API test class - Draft 1

Attached is a simple Java class that can be used to exercise the majority of the methods in a compliant Java implementation of the proposed DDR Simple API.

Note, this draft does not validate the error use cases, where exceptions are defined in the specification. I expect this to be in an update.

---Rotan (chair).

<<DDRSimpleAPITester.java>>

DDRSimpleAPITester.java (19K) Download Attachment

Workshop notice

2008-06-03T04:34:44Z

Workshop notice

The Workshop on the Role of Mobile Technologies in Fostering Social Development [1] is taking place (yesterday and today), and among the issues being considered is that of dealing with diverse delivery channels (mobile phone, low-cost laptop etc.). It is certainly possible that a DDR technology, such as that proposed by the DDWG, will have a future role in supporting Web-based services in these diverse contexts.

Position papers and presentations can be viewed online [2].

[1] http://www.w3.org/2008/02/MS4D_WS/

[2] http://www.w3.org/2008/02/MS4D_WS/agenda.html

Nabble - w3.org - public-ddwg

Warning Notice!!!

RE: Unwanted (?) exceptions in DDR Simple API spec

RE: Unwanted (?) exceptions in DDR Simple API spec

RE: Unwanted (?) exceptions in DDR Simple API spec

Unwanted (?) exceptions in DDR Simple API spec

RE: AskPythia, an implementation of the DDR Simple API in PHP

RE: AskPythia, an implementation of the DDR Simple API in PHP

RE: AskPythia, an implementation of the DDR Simple API in PHP

AskPythia, an implementation of the DDR Simple API in PHP

Re: [mymobileweb-support] REST version of the DDR Simple API

RE: REST version of the DDR Simple API

REST version of the DDR Simple API

New version of TID's DDR Simple API Implementation

DDR API implementations

Device Description Repository Simple API is a W3C Recommendation

Implementation report on Morfeo's DDR Simple API

W3C Workshop on Security for Access to Device APIs - London, December 10-11

RE: [API] Mistake on section 4.3.2.1

RE: [API] Mistake on section 4.3.2.1

[API] Mistake on section 4.3.2.1

Perl implementation of DDR Simple API

DDR Simple API implemented successfully

RE: Structures Editor's Draft

Re: Structures Editor's Draft

Structures Editor's Draft

Device Description Repository 1c

Exploiting Groups of Devices for Content Adaptation

Editors' Draft 16 June 2008

Abstract

Status of this Document

Revision Description

Table of Contents

Appendices

1 Introduction

2 Device Grouping based on XML

2.1 The deviceStructures element

2.2 The vocabularies element

2.3 The vocabulary element

2.3.1 Attributes

2.4 The groups element

2.5 The group element

2.5.1 Attributes

2.6 The expression element

2.6.1 Expression Syntax

Grammar for group expressions

3 Extended Simple API

3.1 Initialization

3.2 Query Methods

4 Example

4.1 XML group definitions file

4.2 Java Code

A References

B Acknowledgements

Updated DDR Simple API test class

RE: DDR Simple API test class - Draft 1

Re: DDR Simple API test class - Draft 1

RE: DDR Simple API test class - Draft 1

RE: DDR Simple API test class - Draft 1

RE: DDR Simple API test class - Draft 1

Re: DDR Simple API test class - Draft 1

RE: DDR Simple API test class - Draft 1

DDR Simple API test class - Draft 1

Workshop notice

2.1 The `deviceStructures` element

2.2 The `vocabularies` element

2.3 The `vocabulary` element

2.4 The `groups` element

2.5 The `group` element

2.6 The `expression` element