[whatwg] [WA1] The profile Attribute
Lachlan Hunt
lachlan.hunt at lachy.id.au
Sun Apr 17 04:42:38 PDT 2005
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
More information about the whatwg
mailing list