Re: head@profile: another dropped attribute

Maciej Stachowiak 2009-02-05 02.36:
> On Feb 4, 2009, at 4:20 PM, Larry Masinter wrote:

>> In particular, whether *attributes and features* 

> - What is the purpose of this *feature*? What use cases does it serve?
> - If the *feature* is already deployed, then how well is it serving its 
> use cases? Is it used at all? When used, does it serve the intended 
> purpose?
> - Does the *feature* cause harm, for example by fostering bad practices, 
> either directly or indirectly (by being error-prone, or easy to abuse)?
> - Does the harm of the *feature* outweigh the benefit?

Maciej, I note that Larry said "attributes and features".

In that regard, @profile is not the feature here. Linking to a 
profile and getting the UA to make use of that profile, *that* is 
the feature. And profiles do exist "in the wild".

The problem is that the draft doesn't whether talk about the 
profile concept or about the profile attribute or about using 
<link> to link to profiles. (Despite Ian's advocacy for <link>, he 
has't added any Link Type for linking to profiles via <link>.)

Thus, as it seems to be very little resistance (am I wrong?) 
against the very profile /concept/, the feature issue with regard 
to the profile /attribute/, has to do with compatibility with 
existing specs, produces, consumers and author knowledge.

However, coming back to the very profile /concept/, when are we 
going to discus /that/? Because, the existing profiles have been 
"digged out" - or literally dedused - from the very thin info that 
the HTML 4 spec has. E.g. see the XHTML Meta Data Profiles page:

http://Gmpg.org/xmdp/description

Thus, regardless of @profile or <link> or both, HTML 5 has, IMHO, 
to define how one is supposed to set up profiles and what HTML 5 
means by profiles.

HTML 4 spesificly says that it does not define any profile format. 
However, history has shown that such a defintion is needed. 
History has also shown that profiles are popular.

And in that regard, HTML 4 says about the <META> element that "the 
permitted values" for the @name, @content, @scheme and @http-equiv 
  "are profile dependent". The real life profile for many  of 
these attributes seems to be Google ...

>  From the implementation point of view, there is no cost to <head 
> profile=""> being conforming. We must support the 
> HTMLHeadElement.profile property in any case for compatibility. I would 
> guess the developers of other browsers are similarly agnostic on this 
> one. I believe the decision to drop profile was made based on 
> considering the needs of authors, although that assessment may have been 
> incorrect.

It is your mention of authors that had me start thinking about the 
above ... Authors needs the profiles concept. Do they also need 
@profile? Would it be a problem for them to use <link> instead? 
Would it be a benefit to use <link> instead? The one benefit I 
could think of would be that using <link> is probably more well known.

Assuming that there were benefit in going for <link>, could we 
include both @profile and <link> for ultimate compatibilty? Of 
course, that could be confusing. But what about this:

<head profile="html5-default-profile-URI">
<link rel="profile" href="realProfileURI" >

Explanation:
In HTML 4 the profile attribute is implied. Thus, there is always 
a profile - namely the default profile of HTML 4. Thus, at least 
per the letter, we could have said that the default profile for 
HTML 5 has moved the profile linking to the <link> element. Hence, 
we could have said that @profile was implied, but that, for 
compatibility, it was also permitted to insert the default profile 
of HTML 5 via profile="" and a specified URI. We could then limit 
the conforming content of @profile to just one single URI, namely 
the "super-profile-URI" of HTML 5.

Here also we are touching on the /concept/ of profile ... It would 
be beneficial to define what the default profile for HTML 5 is - 
that is: what it covers. I think we should at least say that it 
covers the HTML 5 link relations. But also other things.
-- 
leif halvard silli

Received on Thursday, 5 February 2009 04:50:10 UTC