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

On Apr 3, 2010, at 17:23 , Shane McCarron wrote:

> Ivan,
> 
> I appreciate your participating in this discussion whilst on holiday.  If at any time you want to pause it, please just say so.  Everyone deserves a holiday.

I took your advise:-)

> 
> Ivan Herman wrote:
>> 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.
>> 

Still exploring the possibilities; ie, I try to argue with the technical points here to see if we really have to go the way you propose:-)

> Well.... I think this would be cool, but all of the issues with retrieving additional external resources remain. And in my opinion this makes them worse.  Remember that we have no announcement mechanism.  There is no way for the processor to reliably know what sort of document it is reading.  

Reliably: yes, that is true. But, as I said in my earlier mail, defining such mechanism for Media types/suffix is not so complex. The processor could

- look at the media type for documents retrieved on the web and suffixes for files on a disk
- we could have a registration mechanism that makes a mapping from a media type to a readable description of the features. But keeping those language specific features as small as possible, this is not impossible, shall we say (and a processor would obviously cache for text/html, application/xhtml+xml or application/svg+xml)

> I imagine we could work around that by defining a default Host Language, but someone would complain that the default wasn't their favorite.  

Default Host language is application/xml. I do not believe that would be controversial. 

> If you want to embed the required processing logic in an external document, then we MUST address the problems of fail-over and announcement.

You mean if things are not reachable? The fall back is application/xml


>> 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.
>> 
> 
> Yes, someone else suggested the same thing.  I don't mind this because it provides for generic extensibility.  But I would still like to make the hard coded default prefix URI the XHTML vocabulary, and embed the rule about case-insensitivity for that vocabulary because that means legacy documents work and anyone who sets that as a default vocabulary will get that behavior (e.g. rel='license' or rel='LICENSE').  Moreover, in the event you reference a term with a leading colon in ANY document, you will always get what you want (e.g., rel=':LICENSE').

If the mapping above also says that for a specific media type here is the default @profile, would not that solve the issue?

> 
>> - 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..."
>> 
> 
> Sure - this could work.  And I like the idea of putting extension hooks at approved points in the sequence.  We would need to work out the concept of precedence.  

True. And I would be perfectly happy to say that any aliased attribute has a lower precedence than their RDFa equivalent (which is in line with the way we do it right now.)

> And there are a number of points in the sequence where these hooks *could* be placed.  I think it is pretty complicated to express in prose, although in code I imagine it would be straightforward.
> 
> Having said all of that...  Just because we *can* do a thing doesn't mean we *should*.  A frequent comment about RDFa 1.0 is that it is too complex.  Sometimes that is said about authoring, sometimes about implementing.  I don't personally agree, but I could see how the people who say that would have a field day with additional complexity like this.  In addition there is the general case problem of announcement, discovery, and retrieval I mentioned above.  In the case where we don't know what sort of document we are parsing, we won't know what rules to load.

application/xml

> If we guess, we might guess right.  If we use a default, we will at least know something.  Once we DO know something, then we can try to load the rules.  If loading them fails, then we have the additional problem of processing a document without knowing all of the relevant rules.  Potentially this will result in either fewer triples or more triples - certainly it will result in unresolvable, incorrect triples.  To me this is unacceptable.
> 
> What do I mean by unresolvable?  Well, in some of the proposals to deal with external prefix declarations, there were options for resolving the prefixes later.  But those proposals all assume that the relevant triples were extracted from the source document.  If we don't know the processing rules, we are going to MISS some triples (we don't know to make a new subject on @src) or we are going to generate WRONG triples (we see @resource and make that the current object resource, binding it to some current subject inherited from a parent node, but we should have bound it to some other subject or bnode that was on @foobar).  In my mind, this is disastrous.

Again: I do think any reasonable implementation would cache for the deployed languages like html or svg. Ie, I am not sure the deployment features are so disastrous. But I agree with your remark above that this means an extra complication for implementers and that these wrong triples are indeed, well, really really wrong...

Nevertheless, look at it the other way. What you say is that if, in SVG, I mistakenly use the term 'next' somewhere, without any qualifier or default prefix URI, I would suddenly get a term in the XHTML namespace. That would be absolutely unnatural, SVG has nothing to do with HTML...


> 
> Moreover, you have mentioned only @href and @src.  What about @rel, @rev, and @content?  They are all from XHTML too.  And they are not aliases for anything.  Without @rel / @rev in the processing rules, we can't really define predicates at all!  Without @content we don't have any mechanism for overriding literal content of an element when we DO have a predicate!  Surely you are not going to propose that we pull these out as well?
> 

Right, I have to agree with that. I guess the difference is that @rel/@rev are absolutely necessary for the creation of triples, ie, the goal of RDFa, whereas @href and @src are really aliases. We even accept restrictions on their usage (no CURIE-s) that are solely because of their role and usage in XHTML.


>> - 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...
>> 
> 
> Well - on this point I guess I could agree.  Actually, I have always thought the rules were wrong.  I would prefer that we remove them altogether, instead saying that @about defaults to "" at the start of processing and inherits down.  I can't remember why we didn't do that in the first place - it makes no sense to me.  But if we change the rules (note there is already an 'issue' about this in the current Editor's Draft) then aren't we breaking with backward compatibility when processing occurs in the absence of a loaded RDFa Profile document?  Mark, can you remember why the rules are as they are?
> 
> And let's not forget about the base element.  RDFa Core indicates that a language binding can define special rules for the processing base.  XHTML+RDFa and HTML+RDFa would have special rules.  Other languages might incorporate @xml:base.  These rules are not going to be easily discoverable from an external RDFa Profile - at least not in an algorithmic way.  I suppose we could have some rdfa: terms that mean 'process base like in (X)HTML' or 'use xml:base'.  But that's not really generic.  We would also need some rule that says 'element foo sets base globally' or 'element foo sets base in scope' or 'attribute foo is an alias for xml:base'.  Oh yeah, and you need a way to establish precedence:  'foo is an alias for xml:base.  When foo AND xml:base are both specified, xml:base takes precedence'  or whatever.  Seems like an awfully long row to hoe for a feature that, you have to admit, is not going to be used by very many people.

Yes, base is a problem.

Which leads me to explore a simplified approach, which is simply based on the fact that we have a legacy here. Let us not try to be so very general here because, indeed, that leads to too much complications. But I think it is perfectly possible to define

- An RDFa Core where there is no reference to <head>, <body>, <base>, xhtml namespace for default prefix, case insensitivity for terms, etc, nor is there a mechanism to adapt those
- An RDFa HTML that is defined for the media types application/xhtml+html, text/html, or, in case for local files, for .html and .xhtml, and that defines a slightly modified version of RDFa Core with all the necessary additions.

That is. A third language does not really have any other choice than to follow the RDFa Core. Well, they can define things alongside of the the RDFa HTML version but there is no guarantee that a generic RDFa processor would implement those.

Implementations will have to differentiate between HTML and everything else but, in fact, this is already something they have to do today if they want to manage SVG. But there is no need for the complete generality of reading in files, defining a vocabulary for aliases, etc, etc.

How does that sound?

Ivan  



> 
> Okay, that's enough for now.  I have a baseball game to attend!
> 
> -- 
> 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





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