[whatwg] [WA1] The profile Attribute

[Ian Hickson]

On Sun, 17 Apr 2005, Lachlan Hunt wrote:
> > 
> > Imagine you use publicly available profiles A and B.
> > 
> > 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.

There is no way we are requiring a new URI every time the profile changes. 
That would be an administrative nightmare for editors, authors, and UA 
implementors. It would make working out common semantics nigh on 
impossible. IMHO, anyway.


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

Namespaces are not an option. Authors simply don't understand them.


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

I don't really understand that.


> > 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".
> 
> That's a valid use case to avoid profiles with conflicting definitions, 
> not against multiple profiles in general.

That sounds nice in theory but in practice it's not really something you 
can control. Even when one group of people are in charge of two profiles, 
you can end up with duplicates. (An example of this being the way XForms 
and XHTML2, which are done by a lot of the same people, has had clashes.)


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

Agreed. That will probably happen at some point. (It's on my list.)


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

I don't think that's workable. For example, it means every time you 
upgrade to a more recent profile, all the old UAs will stop rendering your 
page -- it doesn't have a workable backwards compatibility migration path.


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

The advantage you get out of this doesn't IMHO outweight the problems.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'