The Mozilla Project
Directions of the Mozilla RDF engine:
website scripting, standards conformance and perfomance

Axel Hecht

RDF Module Owner, Mozilla

Outline

• Short outline of the current design
• Outline major weaknesses
• Upcoming design/API
• Diskussion

RDF run through

What's RDF, anyway?

• Resource Description Framework, W3C specification
• Labeled directed graph, math-speaking
• Describes resources, identified by URIs
• Aggregation of graphs

Current design

• RDF service, factory for all RDF objects, uses
  • rdf: scheme for native RDF datasources
  • resource factories per scheme for RDF resources
• singleton-per-URL data sources, RDF/XML or XPCOM objects
• Resources (singletons), rich data with
  • scheme-based factories
  • delegates
• Literals (String), Date, Int, Blob

Issues

• Lack of standards compliance with 2004 specifications
• (Re-)Loading of RDF/XML data sources
• Only XPCOM (rdf:foo) or RDF/XML data sources (think N3, turtle)
• API mixes internal and public interface
• Current delegates model broken (reference count cycles)
• snapshot-based API with performance/memory problems
• RDF resource factories and security checks

Tasks to tackle

• Compliance work

  Mainly RDF/XML parser/serializer work

• API work

  Exposing better APIs, to both core code base and web applications

• API

  Low level APIs only, exposing commonly performant queries, simple asserts

Compliance

• RDF/XML specification woes bug list (incomplete)
• Typed literals
  • URL for types should be rdf:datatype, is NC:parseType
  • Literal datatypes moved over to XML schema
  • XMLLiteral
• Non-namespaced attributes

Proposed APIs

• Parallel set of APIs, deprecating status quo
• Wordings of current specifications
  subject -> predicate -> object instead of
  source -> property -> target
• Callbacks for data source query results instead of snapshots
• Move singleton-handling to XPCOM services for native data sources
• RDF/XML and other RDF formats instantiated explicitly, explicit instance control
• Using error reporting facilities of the toolkit

Smooth migration

• Parallel existance of APIs
• Backwards compatible (as far as possible)
• Incremental porting of the code base to the new APIs
• Evangelising use of new APIs in the extension developer community
• Documentation on devmo
• BUT:
  • Death of resource factories
  • Incompatible changes to delegates

New APIs: Wording

• Moving to the wording of the 2004 specifications
• Lowering the entry barrier
• Migrating documentation from www.mozilla.org to devmo as we go
• Explicitly deprecating legacy information

Old APIs: snapshots for query results

• Every query API returns a nsISimpleEnumerator
• ... or just the first item of the result
• Enumerators are array based snapshots of the query result
• Bad:
  • Reference counting, once in the array, once in the QueryInterface
  • Allocation and reallocation of array

New APIs: callbacks for query results

• Every query API will work on the same interface rdfITripleVisitor

  interface rdfITripleVisitor : nsISupports
  {
      void visit(in nsIRDFResource aSubject, in nsIRDFResource aPredicate,
                 in nsIRDFNode aObject, in boolean aTruthValue);
  };
  

• Like this:

  function aTripleVisitor(aSubject, aPred, aObj, aTruth) {return;}
  someDS.visitAllTriples(aTripleVisitor);

• Depending on query, some arguments may be null
• No reference counting, correct data type for subject and predicate
• No array allocation/reallocation unless required (and implemented) by the caller
• Early abort possible via Components.returnCode

Old APIs: Resource factories and delegates

• Resource factories create rich objects for web content
• Just bad as long as constructors don't modify data
• ... resource factories will die
• Fuzzy ownership rules for delegates, current use in our code leaks

New APIs: Clear ownership for delegates

• Bug 286592
• Three ownership models, based on different ownership
• Strong ownership, resource holds strong reference to delegate, delegate may outlive resource (hover for diagram)
• Weak ownership, delegate implements nsIWeakReference, resource holds weak reference to delegate, resource may outlive delegate, delegate may hold strong reference to resource (hover for diagram)
• Dual ownership, deserves a slide of its own

New APIs: Delegates dual ownership

• Delegate exposes two nsISupports
• ... to resource
  • implements nsIInterfaceRequestor
  • deletes object when refcount drops to 0, i.e., no more references from the resource to the delegate
  • Inner object
  • Calls to getInterface call QueryInterface on outer object
• ... to rest of the world
  • Exposed by getInterface on inner object
  • QueryInterface does not delete object when refcount drops to 0
  • ... but strong references to the resource must be released then

Load and Save

• Current architecture, singletons for RDF/XML and XPCOM objects
  • No control over loading so far
  • No report on XML errors
  • No write-back-to-server
• Singleton XPCOM services, explicit XPCOM objects for content based data sources
  • Explicit control over lifetime
  • Load and error feedback guaranteed
  • Less reload problems
  • Better architecture for new data source objects, in addition to RDF/XML from URL
  • ... including save-over-the-wire supporting back ends

Web applications

• Post-API work
• Choosing the right subset exposed to untrusted content
• RDFService exposed as window.RDF, grants access to resources and literals
• Constructors for common data sources
  • RDF/XML, loading with same-origin security checks
  • Composite data source
  • In memory data source
  • JS objects implemented in remote content
  • Other objects via extensions
• Helper objects with constructors, ContainerUtils
• Others by extension, for example sparql implementations?

Utopia

• clean up http://home.netscape.com/NC-rdf#
• Bug 12161
• 5 digit bug number
• Whatever you do, don't introduce new uses
• New vocabularies should go through RDF moa

Credits

• The Titans:
  • Ramanathan V. Guha
  • Chris Waterson
  • Robert Churchill
  • Dave Hyatt
  • Dan Brickley
  • Chase Tingley
• The peers:
  • Benjamin Smedberg (he did the diagrams, too)
  • Mike Shaver