Re: RDFa Core Review: Host Language conformance

On 5 Jan 2011, at 22:57, Toby Inkster wrote:
> On Wed, 5 Jan 2011 17:40:27 +0000
> Jeni Tennison <jeni@jenitennison.com> wrote:
> 
>> 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.
> 
> Ultimately, as things are now, a host language can make whatever
> changes it likes to RDFa Core processing. The examples you cite are
> actually quite minor compared to how RDFa has been adopted in
> OpenDocument.

OK. What I'm looking for here is something in the spec that more clearly states what RDFa Host Languages are and aren't allowed to do while still claiming to be RDFa Host Languages.

That might range from:

  "Host Languages may define how RDFa attributes are interpreted and used, and may invent their own attributes and processing rules while still being conformant RDFa Host Languages."

via:

  "Host Languages may alter the processing rules defined in this specification by [list of specific ways in which they can be altered]."

to:

  "RDFa Host Languages must not define any additional processing that either changes or removes the triples that are generated from the RDFa Core processing defined in this specification."

The first clearly makes it impossible to create a generic RDFa processor. If that's the intention, that's fine, it just seems to me to make specifying the processing rules in RDFa Core a little pointless.

> Firstly, OpenDocument is zipped XML files. Secondly it has a
> construction along these lines:
> 
> 	<paragraph>
> 	  Foo bar <start property=":example" name="x"/>quux
> 	</paragraph>
> 	<paragraph>
> 	  xyzzy<end name="x"/> garb.
> 	</paragraph>
> 
> Which would produce (putting whitespace issues aside) this triple:
> 
> 	<> :example "quux xyzzy" .
> 
> Ultimately I think market forces will keep host languages in check. If
> you're producing an XML-based language for a fairly obscure use case,
> and want to allow RDFa to be embedded in it, then you're going to want
> to stick pretty closely to RDFa Core unless you want to spend your life
> begging RDFa consumer implementers to add special cases for your markup
> language. If you're revising an already popular XML format to include
> RDFa, then implementers are more likely to be willing to meet you
> half-way.

If that's the case, then I think you're going to have to relax the constraints on conforming RDFa processors which say things like:

  "A conforming RDFa Processor must make available to a consuming application a single RDF graph containing all possible triples generated by using the rules in the Processing Model section."

and

  "A conforming RDFa Processor may make available additional triples that have been generated using rules not described here, but these triples must not be made available in the default graph."

It seems inconsistent to say that conforming RDFa Processors must follow the RDFa Core processing rules, but that Host Languages are free to specify completely different processing rules while still being conformant.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Thursday, 6 January 2011 11:23:05 UTC