[whatwg] [WA1] The profile Attribute

[Lachlan Hunt]

Ian Hickson wrote:
> On Sun, 17 Apr 2005, Lachlan Hunt wrote:
> 
>>1. There are no reasons there to avoid multiple profiles all together,
>>   only reasons to avoid profiles with conflicting definitions.
> 
> Imagine you use publicly available profiles A and B.
> 
> A has definitions "foo" and "bar".
> 
> B has definitions "baz".
> 
> You use foo, bar, and baz extensively in your document.
> 
> Two months later, the author of profile A updates his profile to include 
> the definition "baz", meaning something completely different to the 
> definition from profile B.

Well, I'd say the author of profile A has broken some rules by not 
keeping the URI for an old version persistent.  Profile authors should 
(hopefully) be smarter than that.  Even when XFN was updated from 1.0 to 
1.1, a new URI was given to avoid altering the semantics of existing 
documents in any way.

I'd say the chances of the above occuring are slim, and not worth 
affecting the ability to make use of multiple profiles.  The spec could, 
instead, provide a strong recommendation for profile authors to keep 
profile versions persistent.

> Your document has now radically changed meaning, yet you didn't use 
> profiles that had clashing meanings when you wrote your document.

In which case, I'm sure many authors would be complaining to the profile 
author about such a change, and I still don't think the spec needs 
unnecessary restrictions for this small use case.

> The only way I can see to avoid this is to use only one profile, since
> then you can't ever get clashes.

There are other ways I've seen proposed, such as using namespaces:

http://www.protogenius.com/rel-schemas/draft-scheid-rel-schemas-00.htm

Although that proposal doesn't seem to even make use of the profile 
attribute, but rather link elements which would be a big improvment over 
the profile attribute.

> Imagine you use publicly available profiles A and B.
> 
> A has definitions "foo" and "bar".
> 
> B has definitions "foo" and "baz".
> ...
> Someone uses a browser that supports only profile B. Now your document 
> will be rendered or processed with completely different semantics, because 
> the UA thinks that by "foo" you mean B's "foo".
> 
> Your document has now radically changed meaning,

That's a valid use case to avoid profiles with conflicting definitions, 
not against multiple profiles in general.

>>3. That also forces unnecessary restrictions on which profiles a UA may
>>   support and process.  For example:
>>
>>   * User Agent A implements XFN
>>   * User Agent B implements RelLicence
>>   * A document uses both XFN and RelLicence, and specifies XFN first
>>     in the profile attribute.
>> ...
> 
> That's a fair point, but implementing XFN for user agent B might be simply 
> a matter of dereferencing the profile URI, downloading the XMDP 
> description (or whatever we end up specifying should be at the end of 
> profile URIs -- something will eventually be specified) and ignoring the 
> values from that profile.

If it is defined that the resources referenced by the profile attribute 
should be XMDP (which would be a big improvement over HTML4, which 
leaves the format explicitly undefined), and UAs were able to download 
the profile and determine its values, then that would solve a lot of 
problems.

> Changed "changes" to "introduces new definitions", which is what I meant. 
> A profile should never drop values it previously defined, and this will be 
> mentioned in the relevant spec when that gets defined.

A profile version should never introduce, drop or change values and 
semantics.  If values are added, changed, deprecated or removed, a new 
version with a new URI should be publised.

> The author can't always know when the profiles he's using will end up with 
> clashes in the future.

They can if profiles remain persistent and although persistence can 
never be guarenteed with 100% certainty, such changes are a small use 
case that's unlikely to occur.

-- 
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/     Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox