Re: RDFa API - global object

Hi Shane,

Yes, you're right.

But the sub-text of my point is that this reflects that we're trying
too hard to make this whole API independent of the browser, and
therefore producing something that doesn't scratch anyone's itch.

We've produced a DOM-independent RDF API, and I would really, really,
like us to produce a DOM-based *RDFa* API.

If you see what I mean... :)

Regards,

Mark

On Thu, Apr 29, 2010 at 1:11 PM, Shane McCarron <shane@aptest.com> wrote:
> I actually agree.  The examples notwithstanding, I had assumed that in a
> real JavaScript implementation the 'rdfa' class of interfaces and properties
> would be attached to the document object.  It doesn't make any sense
> anywhere else - triples are always in the context of a document in RDFa; if
> only so you understand their progeny.
>
> I also don't think this is a big deal nor a big change.  We can do it at any
> time if the group agrees.  It doesn't even change the interface
> declarations.  Just the implementation strategy for JavaScript and updates
> to the examples to make it clear.
>
> Ivan Herman wrote:
>
> Hopefully I understand the main thrust of the discussion here, though I was
> a bit absent on the API discussion. But I think I agree with Mark here on
> the general message...
>
> For me, the main, major importance of the API is to be able to develop Web
> Applications (ie, these goodies running in browsers) with RDFa included. In
> this sense it should follow the same style as other API-s do that are
> developed in this area. It seems there is a API-Development-Franzy these
> days in HTML and Web App land and our API should be in the same style; that
> should be our goal.
>
> From my non-HTML-Developer's point of view, ie, an RDF developers's point of
> view, the RDFa API has a much lower priority an interest, frankly. For an
> environment like Jena, Redland, or RDFLib, RDFa is just another
> serialization of RDF; it is, essentially added to those systems as yet
> another parser, alongside RDF/XML, Turtle, or similar. I do not see huge
> priority in providing an RDFa-specific API for those systems, just as there
> is no such thing as a Turtle API.
>
> Our goal is that people would create Web Applications with RDFa (and RDF
> data in general) included.
>
> I am not sure I made any contribution to the discussion, though:-(
>
> Ivan
>
> On Apr 29, 2010, at 05:43 , Mark Birbeck wrote:
>
>
>
> 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)
>
>
>
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> PGP Key: http://www.ivan-herman.net/pgpkey.html
> FOAF: http://www.ivan-herman.net/foaf.rdf
>
>
>
>
>
>
>
> --
> Shane P. McCarron                          Phone: +1 763 786-8160 x120
> Managing Director                            Fax: +1 763 786-8180
> ApTest Minnesota                            Inet: shane@aptest.com
>
>

Received on Thursday, 29 April 2010 13:58:10 UTC