Re: Issues to record

Ben Adida wrote:
> 
> Ivan wrote:
>> ISSUE: what is the action if the value of @rel, @rev, @instanceof,
>> @property are empty (ie, "")?
>>
>> My proposal: do not generate any triple
> 
> To be clear, you're proposing no new triple, but chaining should still
> occur, right? 

Exactly.

>                This is an interesting proposal for those advanced cases,
> and I see the appeal. I certainly like this a lot more than [_:] :) (can
> you tell which one is the smiley?)
> 

I can:-) And yes, it makes _: unnecessary indeed! And, in any case: this
corner case must be precisely specified for interoperability anyway...


>> ISSUE: what is the action if the value of @rel, @rev, etc, are not
>> namespace backed, ie, no ':' is included?
>>
>> Alt 1: do not generate any triple
>> Alt 2: generate the triple in the xhtml namespace
>> Alt 3: generate the triple in the xhtml namespace for the <link> and
>> <meta> elements (for backward compatibility with HTML metadata notation)
>>
>> My Proposal: a preference for #3
>>
>> Mark claims that this has already been resolved in the past; if so,
>> forget about this, and put it on the account of me being careless:-)
> 
> Indeed, we already decided that special values would be handled
> specifically by the RDFa profile for the host language. In fact, we had
> talked about a namespace-level hGRDDL profile for this, something that
> would rewrite rel="next" to rel="xhtml:next" automatically for just this
> kind of inclusion of default XHTML meaning.
> 
> So I support Alt 3. TimBL will shoot us if we do Alt 2. ;)
> 

Hm. That leads to the discussion we had with Mark yesterday on what you
seem to call 'default rule'. You (and Mark) seem to suggest that a
parser should recognise a certain number of predefined values for the
@rel in <link> (and @name in <meta>) and use them in the XHTML
namespace. I can see the value of that, but this incurs the danger of an
RDFa parser continuously lagging behind the evolution of XHTML or HTML.
Indeed, how can you ensure that a new version of (X)HTML would not
introduce new values that then an RDFa implementation would not properly
handle?

That is why I was thinking of a more general, but future-proof approach
which applies this rule (ie, adding the XHTML namespace) for *all*
non-qualified property names in the header. Ie, if I write

<link rel="ABCD" href="..."/>

This means

<link rel="xhtml:ABCD" href="..."/>

Ugly? Yes, in some ways: the "ABCD" property may not correctly belong to
the xhtml namespace and therefore the generated RDFa would become
incorrect. True. But note that we do not make any check anywhere either;
ie, if somebody puts <span property="foaf:bla"> then nobody checks
whether 'bla' is a valid term in foaf...

>> ISSUE: should we accept @name as an alternative to @property for the
>> <meta> element?
>>
>> Alt 1: yes, but a possible @property has a higher priority
>> Alt 2: no
>>
>> Proposal: #1 (to ensure backward compatibility, so to say)
> 
> I think we don't need to do this in every case, in fact it doesn't make
> sense in every case. It only makes sense if they're using a reserved
> word in the @name, in which case we can already trigger a rule that maps
> @name to @property.
> 
> So, in the *general* case, I say NO. But as part of the "default rules
> for the host language" of course I would see:
> 
> <meta name="reserved_word">foo</meta>
> 
> changes to
> 
> <meta property="xhtml:reserved_word">foo</meta>
> 
> given default host language rules.
> 

Hm. This seems to be the same issue as above. My proposal, more
precisely, said

<meta name="anything">foo</meta>

meaning

<meta property="anything">foo</meta>

and the let all the other rules play their role, ie adding xhtml if
anything is not namespace aware (or keep it as is if it is).

It is the same issue as above because it raises the issue of what the
'reserved words' are...

Ivan


> -Ben
> 

-- 

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