ISSUE-74: Host Language Conformance

Core - Jeni Tennison 2

Host Language Conformance

State:

CLOSED

Product:

LC Comment - RDFa Core 1.1

Raised by:

Manu Sporny

Opened on:

2011-01-13

Description:

From Jeni Tennison:

My second general technical point is around Host Language Conformance, particularly in the use of @href and @src attributes, where the spec notes:

> The working group as not reached consensus as to whether to include the optional attributes in this specification, or whether to have them defined in the relevant Host Language specifications.


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 [1] 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.

Pulling together the statements that are scattered elsewhere in the spec, it appears that the Host Language specification can determine things that aren't expressible within an RDFa Profile. For example, they can:

1. indicate how the *base* URI that's used for the document is determined, for example with HTML specifying it through the @href attribute on its <base> element

2. determine the attribute that's used to indicate the *language* of the content, for example with HTML specifying it through the @lang attribute

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.

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.

Therefore I strongly suggest adding within RDFa Profiles facilities to:

1. specify the path to an element or attribute that sets the base URI for the document
2. specify the name of the attribute used to determine the language

In general, the Host Language Conformance section needs tightening up, to indicate (a) what Host Language specifications need to include and (b) what changes Host Languages are or are not permitted to make in the processing of the RDFa that they contain.

I'd like to see it:

1. explain more specifically what "the facilities required in this specification" (mentioned in the first bullet point) actually are
2. say that any extra Host Language-specific processing rules MUST result in a superset of the triples produced by the RDFa Core processing rules
3. say that Host Language specifications MAY specify an initial list of *term mappings* and SHOULD do so through a profile
4. say that Host Language specifications MAY specify a *default vocabulary* and SHOULD do so through a profile

I think it should also say something along the lines of:

"Host Languages MAY define extra processing that creates additional triples in the *default graph*, but MUST NOT define extra processing that changes the triples that core processing creates."

Coming back to the @href and @src issue described above, it seems to me that if you specify their handling within a Host Language specification, you need to provide a way of programmatically describing their behaviour within the RDFa Profile. Otherwise you're in the situation where Host Languages can introduce new attributes that alter the way in which RDFa is interpreted at a basic level (not just the addition of triples, but changing the triples that would otherwise be generated by RDFa Core).

For that reason, I would either:

1. Add the facility within RDFa Profiles that enables a profile to say "@href provides a default value for @resource; @src provides a default value for @about". (You might consider doing this for other attributes too, if you want Host Languages to be able to reuse their existing @Rel or @Value attributes, for example.) or

2. Keep the @href and @src attribute processing defined within RDFa Core.

Doing the former is going to make it easier/possible to incorporate RDFa into legacy markup languages, but make implementations (and the spec itself) significantly more complicated, perhaps significantly so.

The one thing you should do is to have it specified solely within the (X)HTML Host Language specifications because that means generic RDFa processors can't work with those Host Languages (or others that specify the processing of particular attributes in a similar way).

Related Actions Items:

No related actions

Related emails:

1. RDFa WG telecon minutes for 2011-03-24 (from msporny@digitalbazaar.com on 2011-03-24)
2. RDFa Working Group response re host language conformance [ISSUE-74] (from tai@g5n.co.uk on 2011-03-16)
3. (Attn Shane) DRAFT response to JeniT re host language conformance [ISSUE-74] (from tai@g5n.co.uk on 2011-03-11)
4. Preparing Official LC Responses (from msporny@digitalbazaar.com on 2011-02-06)
5. RDFa WG telecon minutes for 2011-02-03 (from msporny@digitalbazaar.com on 2011-02-03)
6. Telecon Agenda - February 4th 2011, 1400 UTC (from msporny@digitalbazaar.com on 2011-02-01)
7. ISSUE-74 triage (from tai@g5n.co.uk on 2011-01-25)
8. ISSUE-74 (Core - Jeni Tennison 2): Host Language Conformance [LC Comment - RDFa Core 1.1] (from sysbot+tracker@w3.org on 2011-01-13)

Related notes:

Display change log