W3C home > Mailing lists > Public > public-grddl-wg@w3.org > January 2008

RE: GRDDL and powder

From: Booth, David (HP Software - Boston) <dbooth@hp.com>
Date: Mon, 28 Jan 2008 16:31:34 +0000
To: Jeremy Carroll <jjc@hpl.hp.com>
CC: "public-grddl-wg@w3.org" <public-grddl-wg@w3.org>, Phil Archer <parcher@icra.org>
Message-ID: <184112FE564ADF4F8F9C3FA01AE50009DED0A41A79@G1W0486.americas.hpqcorp.net>

To summarize my suggestions regarding the root namespace and the media type:

 - use a POWDER root namespace; and

 - serve as application/xml -- not application/rdf+xml.

These suggestions are motivated by two concerns for clarity:

1. An engineer looking at a POWDER document should be able to easily and clearly determine that it is a POWDER document and has POWDER-constrained syntax.  But if the root element were <rdf:RDF>, then the engineer may reasonably assume that the document is just generic RDF/XML, and thus may make modifications that are unknowingly violate POWDER Lite's additional syntactic contraints.

The only benefit I see for *not* using a POWDER-specific XML wrapper around the RDF is that an RDF processor could directly parse the document as RDF/XML.  But even that does not seem like a significant benefit to me, because an RDF processor is likely to be GRDDL-aware anyway (or certainly should be!), so it will already know how to get the RDF from the XML.

2. Similarly, suppose the POWDER document has a POWDER-namespaced root element, but is served as application/rdf+xml.  The TAG's decision on authoritative metadata

        "Metadata received in an encapsulating container MUST
        be considered authoritative and used in preference to
        metadata found by inspection of the data, declared by
        embedded metadata, or provided by external reference."

So in effect that TAG decision is telling the engineer who receives the document: "Never mind what the document *looks* like.  It is really RDF/XML."  And since the document would properly parse as RDF/XML (using production nodeElement
http://www.w3.org/TR/rdf-syntax-grammar/#start )
then again the engineer may quite reasonably assume that the document is just generic RDF/XML and make changes that unknowingly violate POWDER's additional syntactic constraints.

Finally, I think it would be wise to have a clear syntactic divider between the POWDER Lite and any arbitrary RDF, so it is easy to see where the POWDER-constrained syntax ends and arbitrary RDF begins, as illustrated below.

> Booth, David (HP Software - Boston) wrote:
> [ . . . ]
> For example, a POWDER document might be served as application/xml
> and look something like:
> >
> > <powder:powder ... >
> >   <powder:lite>
> >     [Standard POWDER Lite goes here]
> >   </powder:lite>
> >   <powder:additionalMetadata>
> >     [Any additional unconstrained RDF/XML goes here]
> >   </powder:additionalMetadata>
> > </powder:powder>

I don't have a strong opinion either way about whether the POWDER Lite portion should use a constrained RDF/XML syntax or a custom XML syntax.  Some pros and cons:

 - An RDF/XML syntax would permit the GRDDL transformation to be simpler, as it merely needs to grab and output that portion wholesale.  However, the GRDDL transformation only needs to be written once, so that doesn't seem like a big benefit.

 - A custom XML syntax might be more concise than RDF/XML, so it might be easier for XML-only apps to process.

David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com

Opinions expressed herein are those of the author and do not represent the official views of HP unless explicitly stated otherwise.
Received on Monday, 28 January 2008 16:32:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:39:12 UTC