W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > June 2010

Comments on RDFa API WebIDL

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Tue, 15 Jun 2010 16:43:34 +0000
Message-Id: <1276620199.11715.404.camel@localhost>
To: public-rdfa-wg@w3.org
Hi,

A few comments on the WebIDL used to defined the RDFa API in
http://www.w3.org/TR/2010/WD-rdfa-api-20100608/; this is the result of a
cursory examination, so the review is not exhaustive in any way.

* "object" is used as an argument name in a number of methods, but
object is a reserved keyword in WebIDL

* a contrario, the WebIDL refers to a "Object" interface that isn't
defined; I assume "object" was meant

* rather than allowing any object, it seems to me that a wrapper
interface for IRI, PlainLiteral, TypedLiteral, BlankNode would help
define a more specific API

* it sounds like predicate can only by IRIs, in which case the various
methods that use "Object" as a type for the predicate argument should
use IRI instead

* PropertyGroup and DataQuery uses Sequence[] when I think sequence<> is
meant

* there are also a few cases of Any instead of "any"

* note that sequence<> is not recommended for use in attributes, per 
       "For attributes, it is recommended that a read only array is
       used instead."
       http://dev.w3.org/2006/webapi/WebIDL/#idl-sequence 

* "The RDFa Working Group is considering whether plain literals should
express literal values as UTF-8, or whether the encoding of the source
document should be used instead." 
The WebIDL spec says that DOMStrings are to be interpreted as UTF-16
encoded strings
http://dev.w3.org/2006/webapi/WebIDL/#idl-DOMString

* the proposed WebIDL creates a number of constructors (for
PlainLiteral, IRI, TypedLiteral, BlankNode, RDFTriple) in the global
namespace; they risk colliding with existing usage on the Web (making
their implementation in browsers difficult or unlikely), and are not
very usual in most JavaScript APIs; given that there are factory methods
available from document.data.store, it's not obvious what the benefits
of having these constructors are

* likewise, most interafaces should probably be annotated with
[NoInterfaceObject] to avoid polluting the global namespace

* the examples use a "print()" function, but print() in JavaScript
commonly refers to window.print() which is used to print a page

* the interface Document is in conflict with the interface defined in
HTML5 http://dev.w3.org/html5/spec/infrastructure.html#document
You probably want to define a "supplemental" interface, the same way
e.g. the Selectors API does:
http://www.w3.org/TR/2009/CR-selectors-api-20091222/#nodeselector

Dom






Received on Tuesday, 15 June 2010 17:23:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:06 GMT