Re: thoughts on @profile (ISSUE-55)

Julian Reschke On 09-05-22 15.50:
> Henri Sivonen wrote:
>>
>> On May 22, 2009, at 15:54, Julian Reschke wrote:
>>
>>> RFC 2731 (<http://greenbytes.de/tech/webdav/rfc2731.html>) and 
>>> DC-HTML (<http://dublincore.org/documents/dc-html/>) already define 
>>> a different syntax for that; so; *if* we wanted to do that, we 
>>> should consider just using that.
>>
>> Do existing RFC 2731 or DC-HTML consumers actually do prefix-based 
>> indirection with scheme and refuse to work without profile or do they 
>> just hard-code strings like "dc.title" and ignore both profile and 
>> scheme?
>
> I once wrote a RFC2731-based consumer (it's in an SAP product), which 
> relies on the prefix indirection (@profile is not used in RFC 2731, 
> this was introduced in DC-HTML later on).

Henri's question can be moved one level higher up - to the very profile: 
how is rel="schema.CURIE" is interpreted? For instance, the most common 
DC namespace is defined like this: @rel="schema.DC".

    <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" >

But would e.g. your SAP product have worked if a page wrote 
@rel="schema.FOO",  and linked that to the same namespace and hence used 
"FOO.title" intstead of "DC.title"?

    <link rel="schema.FOO" href="http://purl.org/dc/elements/1.1/" >

>>> In recent discussions, the RDFa people claimed that non-registered 
>>> link relations did not work in HTML 4.01 unless qualified by a 
>>> profile; if there was agreement about that, RDFa would need that as 
>>> well because of the use of CURIEs.
>>
>>
>> My understanding is that stuff like rel=license, rel=nofollow and 
>> rel=prefetch work where supported regardless of profiles.
>
> I agree with that.
>
> So, in practice, new rel values can be introduced without profiles, 
> even though a few people claim the contrary :-).

What happens - in practise - is that the de facto /default/ meta data 
profile of HTML gets extended. I think consumers must "prelearn" the 
meaning and conventions of profiles, including the default one.  
Eventually a linked in profile can tell that in this document these 
values have another meaning. However, even the meaning and/or 
conventions of this linked in profile must be be prelearned.

I think the reasoning goes like this: A profile "x" might say that 
rel="something" means one thing, while profile "y" might say that the 
same rel="something" means another thing.  And this would also apply to 
e.g. Dublin Core values. Hence, profile "x" could say that 
"dc.something" means one thing, while profile "y" could say that the 
same "dc.something" means another thing.  Profile "x" could either do so 
by "occupying" the same prefix (Dubline Core then says that the last 
@rel=schema.something wins over the former). Or profile "x" could 
"hardcode" the meaning of the token "dc.something". (Btw, what if you 
have xmlns:dc="URI", but at the same time a profile is linked in which 
says that the meaning of e.g. "dc:title" is governed by _that_ profile? 
I think actually that the linked in profile should take take presendence.)

Anyway, I see your point: One could have implemented the namespace 
feature of DC - or something similar - in HTML (and XHTML).
-- 
leif halvard silli

Received on Friday, 22 May 2009 17:58:44 UTC