Re: RDFa API - global object

Hi Manu,

On Thu, Apr 29, 2010 at 6:31 AM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> On 04/27/2010 03:36 AM, Toby Inkster wrote:
>> The 'rdfa' object in the current draft appears to be a global object?
>> Is this true?
>>
>> I'd like to propose making it a property of the existing global
>> 'document' object, so you'd access it in Javascript as:
>>
>>       rdfa = document.rdfa;
>
> One can't implement this in languages that don't support Delegation, or
> prototype-based programming.

I agree with Toby, and what's more I think the issue does get to the
heart of one of the major problems with this spec; that it goes way
too far to be browser-independent, and in the process doesn't really
say very much of interest in the context of browser application
development.

I realise that some people want an RDF API, and I'll comment on that
separately. But my main point here is that even putting aside the
RDF-focus of the API as it stands, we seem to have something that is
standalone, rather than a *DOM* API.

So, to go back to Toby's point, if we're building a DOM-based API,
then within the W3C suite of applications and standards, those
interfaces should really be available on the DOM itself.

Note that if this isn't done, then the only way for browsers to
implement the current spec would be to add the APIs to the JavaScript
language itself. W3C specs usually take the factory approach:

  var literal = document.rdfa.createTypedLiteral(
    '2010-12-24',
    document.rdfa.createIRI( "http://www.w3.org/2001/XMLSchema#date" )
  );

(Even if we put aside the spec-related aspects of this, I can't find
another spec that has the root object 'floating' in space, independent
of any DOM or Window object. Can anyone else think of one?)


WEB APPLICATIONS

As an aside, I would argue that what we are creating is something that
is primarily for use in web applications, and therefore the home of
the interfaces should actually be the Window object. HTML5 puts these
kinds of features -- local storage, messaging, etc. -- on the window,
since this is termed the 'browsing context' [1], and I think that this
is the ideal home for our metadata features.

But anyway...Window or Document...certainly a subject for discussion.
But the root object has to be *somewhere*.


SUPPORTING OTHER LANGUAGES

I realise that when I say "primarily for use in web applications",
people will immediately reply 'but this API could be used in so many
other places!'.

Of course. That is after all what computer science is all about. :)

But my suggestion would be that just because we explain our interfaces
primarily through the Window or Document objects -- as I'm suggesting
we should, and I believe Toby is too -- doesn't mean that other host
languages and platforms can't implement the API in other contexts, or
create bindings with other languages.

DOM 2 Events [2] illustrates this idea very well. It's a spec that is
primarily aimed at the DOM, but has been used in many other contexts.
If you look at the overview [3] you'll see how the connection is made
between the DOM and the API; it explains how programmers can easily
get access to all of the interfaces for event registration by
beginning with the Document object.

But if you then look at the appendices you'll see that the IDL
definitions are supplemented with specific language bindings. In this
case one for JavaScript, and one for Java, but there is no reason why
we can't have as many as we like (i.e., as many as people are prepared
to maintain). That then breaks the strict binding between the spec and
the DOM, because anyone is free to implement the interfaces in other
contexts.


OBJECT NAME

Looping back to the beginning, on the name of the object...

In my parser I use 'meta' as the root of all the interfaces, since I
imagined that there might be other metadata interfaces that people
might add in the future, via other specifications. So I would suggest
we have:

  document.meta

or:

  window.meta

as the root for web application developers, and then define that interface.


RECAP

So to sum-up, if the spec is to be a *DOM* API then it needs to
clearly relate to the DOM.

Therefore, at the very least we need to get to the root RDFa object
via Document, and possibly even via Window:

  var meta = document.rdfa;

However, I'd further recommend that this object is called 'meta',
since it will probably be useful for more than just RDFa.

Once we have this object, it is used to create any of the currently
defined objects via factory methods, not directly (i.e., not via
constructors). So we would have something like this:

  var literal = meta.createTypedLiteral(
    '2010-12-24',
    meta.createIRI("http://www.w3.org/2001/XMLSchema#date")
  );

This sequence of using the document or window object to find the
interfaces, and then using factory methods to create objects, aligns
us much more with the style of other W3C specifications, and doesn't
preclude the use of the API definitions in other, non-browser (and
even non-DOM) environments.

Regards,

Mark

[1] <http://www.w3.org/TR/html5/browsers.html#browsing-context>
[2] <http://www.w3.org/TR/DOM-Level-2-Events/>
[3] <http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-overview>

--
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Thursday, 29 April 2010 09:43:52 UTC