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

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.

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.
>   
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.  I imagine we could work around that by defining a 
default Host Language, but someone would complain that the default 
wasn't their favorite.   If you want to embed the required processing 
logic in an external document, then we MUST address the problems of 
fail-over and announcement.
> 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').

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

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?

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

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

Received on Saturday, 3 April 2010 15:24:33 UTC