ISSUE-74 triage

Here are Jeni Tennison's comments (JT) and my replies (TI). In
paragraphs where I suggest an editorial change, I've included the marker
"[EDIT]". In paragraphs where I suggest opening a new issue, I've
included the marker "[ISSUE]".

Unlike some of the LC Comment issues, this can't really be broken down
into smaller chunks. It's really just one concern with multiple facets.
In broad strokes, my reply is that host languages have carte blanche
when it comes to setting their own processing requirements, though we
need to clarify that; host languages with fewer quirks will perhaps find
it easier to get widespread support; if this does prove a problem it's
perhaps one that a future RDFa WG could address; in the present GRDDL
goes a long way to addressing it already, though currently nobody seems
to be using GRDDL as a way of implementing host-language-specific


JT: This seems to come down to how you view the relationship between
RDFa Core and the Host Language specifications. The section on Host
Language Conformance implies that the only way in which a Host Language
can really alter the way in which RDFa is processed is through the
provision of a default profile. However, it seems that it's more
complicated than that.

TI: It is indeed more complicated. The XHTML+RDFa host language
published by this working group alters the processing sequence in a
number of ways not alluded to in RDFa Core 1.1. section 4.2. It provides
the <base> element for setting the document's base URI; it provides two
attributes to set the language for literals (RDFa Core doesn't provide
any, though it notes that xml:lang will likely be used in many host
languages); it provides default about="" attributes on <body> and

TI (cont'd): HTML+RDFa which is published by the HTML working group goes
further by using the HTML5 parsing algorithm to build its initial DOM

TI (cont'd): Although not yet published as a FPWD, I'm working on an
Atom+RDFa note. This sticks far closer to RDFa Core, but also has a
quirk of its own, which is necessary for backwards compatibility with
existing Atom content - it sets a default typeof="" on <entry> elements.

TI (cont'd): Enumerating a list of which differences are allowed for a
host language, and which are not would restrict the ability of existing
XML-based languages from adopting RDFa. For example, if defaulting
typeof="" on certain elements by tag name were not allowed, it would
make an Atom+RDFa host language completely impossible.

TI (cont'd): We should perhaps clarify that the items in section 4.2 are
not an exhaustive list of the ways a host language's processing
requirements may differ from RDFa Core. [EDIT]

JT: It concerns me that the Host Language can specify these aspects of
RDFa processing, but that there's no programmatic way of working out
that they are doing so. This makes it hard to make a generic RDFa
processor: instead you need one that is targeted to a particular Host
Language or that can be invoked with one of a selection of known Host
Languages, detectable through Content-Type or document element or

TI: Although not mentioned in the RDFa Core specification, a technology
does exist that fills this gap: GRDDL. Using GRDDL a host language can
indicate a script (typically XSLT) linked to from its namespace
document, capable of transforming host language documents into documents
that can be processed by RDFa Core - or indeed transforming them into
other RDF serialisations.

TI (cont'd): So far, I do not know of any host languages that provide
such a script, but the existance of a current W3C Recommendation that
allows them to seems to indicate that it is not the lack of a technical
means that is preventing them, but a lack of will or a lack of demand.

TI (cont'd): However there is a strong case for any future RDFa working
group to assess the demand for a programmatic way of dealing with
unknown host languages; investigate whether GRDDL is enough, or whether
something RDFa-specific would be better; and decide whether RDFa host
languages should be required to provide a transformation, and whether
processors would be required to process it.

JT: For example, say that I wrote a Host Language specification for the
legislation XML that I deal with on a daily basis, and said that the
base URI should be ascertained from the dc:identifier child of the
ukm:Metadata child of the leg:Legislation element, and language
determined by the @xml:lang attribute. RDFa Core processors that didn't
know about my Host Language specification would interpret the RDFa
incorrectly. But I don't think it's realistic for me to persuade all
RDFa processors to have a plug-in to handle the legislation XML.

TI: Ultimately, the market will decide which host languages succeed.
(That's true irregardless of what we put in the spec - we can at most
steer it in one direction.) It seems to me that the fewer quirks a host
language has in its processing, the more likely it is to be supported by
processor implementations. If it has no quirks, then it's going to work
out of the box. If it has a few small quirks, then a feature request to
the developer of the processor may result in support being added in the
next release.

TI (cont'd): There are perhaps some host languages where processor
developers will bend over backwards to add support. In these, the host
language designers have a bit more liberty in how they adopt RDFa.
OpenDocument Format 1.2 includes a very weird version of RDFa. (aside:
I'd be happy to go into this in more detail if anyone's interested,
though you can probably find it all on the mailing list archives.) It's
not the RDFa working group's business to decide how OpenDocument chooses
to adopt RDFa, but I think we're mostly happy that they have decided to
do so at all.

TI (cont'd): At what point a host language's adaptation of RDFa becomes
"not RDFa" is a question for philosophers to ask. At what point they
must stop marketing it as RDFa is an issue for lawyers to decide.

Toby A Inkster

Received on Tuesday, 25 January 2011 23:28:59 UTC