Re: @href and @src in RDFa 1.1 Core (Re: Editor's Drafts Updated)

Hi Shane,

I guess we both understand one another's view and we share the concerns. But I am not yet ready to give in...:-) I would like to explore what it would mean to make a cleaner separation and whether this could be defined somewhat more easily. Ideally, I would like to be able to define that through some configuration file that could be managed by an RDFa processor automatically.

I see three issues today which are XHTML specific and which are still part of the Core or are undecided:

- pulling in an earlier discussion, terms in XHTML should be case insensitive. Actually, I just realized that extending the current RDF data with a boolean value saying that certain terms are case sensitive or not can be done fairly easily

[ rdfa:uri ".....#next"; rdfa:term "next"; rdfa:caseInsensitive true ]

If we use the @profile mechanism, that could work, the implementation is easy, and other vocabularies may make use of it if they want.

- the @href/@src issue of this thread. You just said it: these attributes are aliases. So if there is a description that says @src is an alias of @about and @href is an alias of @resource, than the generic processing step can be described by saying in, say, point 7 second item "by using the URI from any alias of @about defined for a language, if present..."

- the exceptional usage of head and body in the processing steps. Actually, that what bothers me the most because it does disturb the logical flow of managing a DOM tree. I would really prefer to move that out into the XHTML document...

Ivan


On Apr 2, 2010, at 16:57 , Shane McCarron wrote:

> 
> 
> Ivan Herman wrote:
>> My view at the moment is:
>> 
>> - @href/@src would not be in core
>> - @href/@src would be allowed in XHTML and HTML5
>> - for other languages we could say that it is of course possible to do what HTML does, but we discourage that...   
> 
> I understand your view, but I disagree.  It would be incredibly confusing for implementors AND authors if we pull the processing rules for @src and @href out of the Sequence section.  I mean, sure, these attributes could become 'discoverable' to an implementation via some mechanism when the implementation accesses the RDFa Profile for a Host Language, but I think it is unnecessary and complicated.  I suspect your point is that these attributes are syntactic sugar, and that their functions are duplicated in @about and @resource.  This is true, but...  it feels wrong to increase the burden on our primary audience.  The only way to deal with that burden would be to make the Host Language specifications 'thick' - where there is lots of duplicated detail so that you don't need to refer back to RDFa Core.  Duplication leads to division and error.  No one wants that.
> 
> -- 
> Shane P. McCarron                          Phone: +1 763 786-8160 x120
> Managing Director                            Fax: +1 763 786-8180
> ApTest Minnesota                            Inet: shane@aptest.com
> 
> 


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