ISSUE-51: Clean up create*** methods for RDF interfaces and move to DataContext

RDF creation interfaces

Clean up create*** methods for RDF interfaces and move to DataContext

State:
CLOSED
Product:
RDFa 1.1 API
Raised by:
Nathan Rixham
Opened on:
2010-10-27
Description:
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.
Related Actions Items:
No related actions
Related emails:
  1. PROPOSAL to close ISSUE-51: RDF creation interfaces (from msporny@digitalbazaar.com on 2010-11-15)
  2. PROPOSAL to close ISSUE-57: TypedLiteralConverter Failures and Exceptions (from msporny@digitalbazaar.com on 2010-11-10)
  3. Re: API question (from nathan@webr3.org on 2010-11-01)
  4. Re: ISSUE-57: TypedLiteralConverter Failures and Exceptions (from nathan@webr3.org on 2010-11-01)
  5. RDFa API new Issues - summary (from nathan@webr3.org on 2010-10-28)
  6. ISSUE-53: DataParser Upgrades [RDFa 1.1 API] (from sysbot+tracker@w3.org on 2010-10-28)
  7. ISSUE-52: Lightweight DataStore aligned with ECMAScript [RDFa 1.1 API] (from sysbot+tracker@w3.org on 2010-10-27)
  8. ISSUE-51: Clean up create*** methods for RDF interfaces and move to DataContext [RDFa 1.1 API] (from sysbot+tracker@w3.org on 2010-10-27)

Related notes:

Closed after time allotted in the PROPOSAL to close the issue and no objections to the PROPOSAL.

Manu Sporny, 2 Dec 2010, 14:40:28

Display change log ATOM feed


Chair, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <w3t-sys@w3.org>.
$Id: 51.html,v 1.1 2015/03/27 14:12:24 vivien Exp $