(Attn Shane) DRAFT response to JeniT re host language conformance [ISSUE-74]

Below is a draft response to Jeni. Sorry this has been a long time
coming. Small editorial change suggested (hence "Attn Shane") - we
should make it clear in RDFa Core, section 4.2 that host languages
pretty much have free reign in defining processing rules. (Hence
XHTML+RDFa beling "allowed" to do things like support <base>, and
provide different handling for <body> and <head>.)

========

Jeni,

This is a response from the RDFa Working Group to your last call
comments on RDFa Core 1.1.

We'd like to thank you for taking the time to review the specification.

You wrote:

> 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.

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 <head>.

HTML+RDFa which is published by the HTML working group goes further
by using the HTML5 parsing algorithm to build its initial DOM tree.

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.

We should perhaps clarify that the list in section 4.2 is not
intended to provide an exhaustive set of the ways a host language's
processing requirements may differ from RDFa Core.

> 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 something.

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.

So far, I do not know of any RDFa 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.

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.

> 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.

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.

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
you're 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.

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.

I'd like to thank you again on behalf of the working group for
your detailed feedback. In the cases where we could not make the
changes you suggest, I hope that you understand our reasoning,
even if you don't fully agree with it.

Could you please let us know if you think the WG has reviewed
your concerns and addressed what we could address, and given
responses to those items we couldn't? i.e. we didn't miss anything
out, did we?

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Received on Friday, 11 March 2011 21:53:19 UTC