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

ISSUE-51: Clean up create*** methods for RDF interfaces and move to DataContext [RDFa 1.1 API]

From: RDFa Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Wed, 27 Oct 2010 02:02:47 +0000
To: public-rdfa-wg@w3.org
Message-Id: <E1PAvLj-00086d-Lm@crusher.w3.org>

ISSUE-51: Clean up create*** methods for RDF interfaces and move to DataContext [RDFa 1.1 API]

http://www.w3.org/2010/02/rdfa/track/issues/51

Raised by: Nathan Rixham
On product: RDFa 1.1 API

This proposal is to:
 - remove `node` parameter from createIRI (cleanup)
 - remove `name` parameter from createBlankNode
 - move create** methods from DataStore to DataContext

IDL for methods to be added to DataContext (and corresponding methods removed from DataStore):

    IRI           createIRI (in DOMString iri);
    PlainLiteral  createPlainLiteral (in DOMString value, in optional DOMString language);
    TypedLiteral  createTypedLiteral (in DOMString value, in DOMString type);
    BlankNode     createBlankNode ();
    RDFTriple     createTriple (in RDFResource subject, in IRI property, in RDFNode object); 


Why remove the name parameter from createBlankNode
It's unneeded, introduces a possible exception to BlankNode construction and encourages people to think of blanknode names as dependable in some way, the unique per context "name" of a BlankNode can be retrieved by calling BlankNode.toString, or the blank node itself can be passed around when referring to it multiple times (such as using the same blank node as the object of one triple, and the subject of another). 


Why move create** methods:
Simply, they don't belong on DataStore, it is of no concern to a DataStore how IRI, RDFTriple, PlainLiteral etc are created. More technically having the create** methods on DataStore decoupled them from the default context which leads to unexpected behaviour, cross cutting concerns and a difficult implementation. Whereas if they are located on the DataContext interface they are always coupled to a specific context, behaviour is expected, dependency is clear and cross cutting concerns are removed. (DataStore cannot see DataContext in any way).


Example issue this resolves:

  var newContext = document.data.createContext();
  var newStore = document.data.createStore();
  var myval = newStore.createTypedLiteral("123", "some:customType");

How does newStore or myVal get access to any context to do the typed literal conversion? if it can somehow see the contexts, which context does it use newContext or document.data.context or some other context?

Compare:
  var newContext = document.data.createContext();
  var myval = newContext.createTypedLiteral("123", "some:customType");
  
Which has no issues.
Received on Wednesday, 27 October 2010 02:02:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:22 UTC