W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > January 2011

PROPOSAL to close ISSUE-29: RDFa API .origin property

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sat, 01 Jan 2011 20:55:30 -0500
Message-ID: <4D1FDB12.8050807@digitalbazaar.com>
To: RDFa WG <public-rdfa-wg@w3.org>
If there are no objections to this proposal in 7 days, we will close
ISSUE-29: RDFa API .origin property needs to be more carefully specified.

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

While discussing how to access the DOM element associated with a
particular triple, it became evident that there was going to be an issue
with storing the originating DOM element on a triple. What happens if
the element disappears? A triple can exist long after an element
disappears. What should the underlying implementation do if a triple's
.origin disappears? Should the value be null, undefined, etc? Should the
.origin change to a new value if RDFa attributes on the element changes?
Supporting .origin started to create more design issues than benefits.

There were several important questions that needed to be answered for
this issue to be resolved:

1. Did we want to be able to access the source element for common RDFa
structures? The general feeling was that we did, but needed a simpler
way to support this mechanism.

2. Do we care about real-time access to triples in the document? The
answer to this question was "yes". The RDFa WG felt that it was
important to be able to access the element that currently holds the
information asked for and reduce the possibility of getting stale
element data. A developer should be able to perform an RDFa query and
extract the information held in the document at the time of query.
Re-synchronizing the RDFa model with the document must be eliminated, or
at least, hidden from the developer.

3. Which element should be retrieved for a particular triple? The answer
to this question was "it depends". In the end, we provided a way to
retrieve elements associated with subjects and elements associated with
properties. Elements associated with objects are not directly supported
by the RDFa API, but can be retrieved by navigating from the element
associated with the property.

4. What happens when an element is deleted? The answer to this was "the
same thing that happens to any other element when it is deleted". Any
variable with a reference is able to access the element, but the
NodeList is updated to remove the element. In short, the behavior of
document.data.getElementsBySubject() should mirror the behavior of
document.getElementsByClassName().

The triple interfaces have been removed from the RDFa API and moved into
the RDF API. The group felt that it was more beneficial for developers
to not have to deal with triples or any of the other RDF data types in
the general case of using the RDFa API. This resulted in much of the
complexity of handling triples being moved to the RDF API document,
leaving the RDFa API document to deal with querying the DOM for the
source of particular subjects and properties.

In the end, the RDFa WG found that we only needed three element
retrieval calls to support all of the use cases listed above. These
calls are summarized in the section entitled "Retrieving DOM Elements"
in the RDFa API document:

http://www.w3.org/2010/02/rdfa/sources/rdfa-api/#basic-concepts

and further detailed in the following section:

http://www.w3.org/2010/02/rdfa/sources/rdfa-api/#the-document-interface

Please comment in 7 days from this post if you object to this proposal.
If there are no objections within 7 days, ISSUE-29 will be closed.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Linked Data in JSON
http://digitalbazaar.com/2010/10/30/json-ld/
Received on Sunday, 2 January 2011 01:56:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:08 GMT