Re: Action item to outline language-dependent features

It sounds good. But my comment is more methodological, so to say. I
think we should begin by fully finalizing the XHTML mapping (which is
very close to completion!), look at the various implementation and usage
experiences and, as a kind of a second phase, write that up, possibly
testing them against a very different language (eg, HTML but, also,
SVG). I am also motivated by a need to get the XHTML version of RDFa out
as soon as possible to use the current positive noises around RDFa...:-)

I.

B.t.w., I am a little bit puzzled by the properties below. If by XHTML
you mean XHTML1.1, then my understanding was that xml:base is not used
but @lang is also accepted... But these are details...


Mark Birbeck wrote:
> Hello all,
> 
> A few issues have come up recently where some feature or other might
> be used by RDFa, but it would be inappropriate to provide that feature
> within RDFa itself. For example, we would like to be able to express
> the language of literals, but it would be overkill (and confusing) for
> us to create our own language attribute when both HTML and XML-based
> languages have such a facility.
> 
> Another example is the use of @xml:base in XML languages; this allows
> fine-grained control over relative paths in mark-up and is a very
> useful feature for RDFa to leverage, but if a host language does not
> provide it then I think we have to accept that limitation, and not
> provide it ourselves.
> 
> We discussed on a telecon recently that one way to approach this whole
> thing is to define some kind of abstract set of properties that a host
> language would provide, and then to map those to specific attributes.
> 
> My suggestion would be to define a 'context' that is then used by RDFa
> parsers, in much the same way that the definition of XPath indicates a
> context for evaluating expressions.
> 
> The properties of the 'context' that we would need for RDFa are (there
> are no doubt others that I have missed):
> 
>   * a current langauge, or 'no language';
> 
>   * a current subject;
> 
>   * a current base URI against which relative paths are evaluated;
> 
>   * a set of prefix/substitution mappings.
> 
> 
> In HTML these context-features would be set in the following way:
> 
>   * language is set using @lang;
> 
>   * subject is set using various rules, such as @href, @resource, @about,
>     @src, @rel/@rev, and so on;
> 
>   * the base URI is set using the current document URL or <base>;
> 
>   * prefix/substitution mappings are provided by ... :)
> 
> (This last point is still not quite resolved, but there are proposals
> floating around.)
> 
> 
> In XHTML the context-features are set as follows:
> 
>   * language is set using @xml:lang;
> 
>   * subject is set using various rules, such as @href, @resource, @about,
>     @src, @rel/@rev, and so on;
> 
>   * the base URI is set using the current document URL, <base> or @xml:base;
> 
>   * prefix/substitution mappings are provided by @xmlns.
> 
> I'm hoping that we can come up with precise names for these
> context-features (and others that I have no doubt missed) so that we
> can define the processing rules very clearly, independent of the
> attributes. We can then also define the behaviour of the attributes in
> terms of these definitions.
> 
> For example, you might define @resource simply by saying "it sets the
> context subject property for all contained RDFa expressions", and that
> might be all that is needed. Then in the processing rules you might
> say "a triple is generated by combining the context subject property
> with the blah blah", and not make any reference to host
> language-specific attributes.
> 
> Regards,
> 
> Mark
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf