- From: Leif Halvard Silli <lhs@malform.no>
- Date: Thu, 27 Sep 2007 07:27:25 +0200
- To: public-html@w3.org
On 2007-09-26 07:22:27 +0200 Sander Tekelenburg <st@isoc.nl> wrote: > At 04:27 +0200 UTC, on 2007-09-24, Charles McCathieNevile wrote: [ About @profile ] >> There is also an extensibility mechanism in HTML 4 based on the profile >> attribute. It isn't very clearly specified in HTML 4 how this should >> actually work. > > Yeah. I was looking at that recently and found it difficult to visualize how > it is intended to work. A problem is that the format of profiles is not > defined. So every profile might well be in a different format, which wouldn't > exactly make things easier for authors (nor for UA developers, I suppose). > > (Perhaps such problems are inherent to extensibility though... I suppose > namespaces are basically the same. Still, namespaces seems like a generally > easier to use approach than profiles.) I think understanding what @profile is and refers to is the problem - not the 'profile format'. (Actually - perhaps it is because we don't understand what profiles are, that we are looking for spesific formats.) HTML4 section 6.11 says that «The current specification uses one of the formats described in the profile [DATETIME] for its definition of legal date/time strings ( %Datetime in the DTD).» That profile is located at <http://www.w3.org/TR/NOTE-datetime>. That page itself defines itself as a 'note'. But also says that it is a «profile of ISO 8601». A profile only needs to have spesific format if it is to be machine read. There are many RFC's which define different 'profiles'. (And an RFC usually isn't machine readble, I guess.) 'profiles' seems actually to be a cross-standard thing - they don't necessarily need to be HTML related. For instance, the [datetime] profile mentioned above is merely a practical interpretation/implementation/short version - profile - of ISO 8601. Profiles seems to be definitions of general things - which can be implemented in spesific implmentations/spesifications. The profile attribute/functionality of HTML4 is a method for reusing things that are specified outside HTML4. [...] > For example, returning to @rel: iCab indicates recognised values through > icons, but accepts and presents other values as well. Although allowing > authors to use just any @rel value wasn't the intent of the HTML 4 spec > (which refers to @profile for such extension), Indeed. The intent probably was that one could reference well defined/well known profiles. I guess the only thing that is 'wrong' with rel=nofollow is that it isn't enforced via the profile attribute. But other than tat, 'nofollow' in rel=nofollow refers to a profile defined by Google. [... profiles and 'the sweet spot' ...] >> "where is the sweet spot between simplicity >> and power that leads to the widest interoperable usage"? > > Simply allowing any value would probably be too simplistic. At the very least > it would result in never being able to add new predefined values, because > those by then may well conflict with existing content. But, assuming > namespaces would make it into HTML, the spec could perhaps define a reserved > namespace, specifically for non-defined values. I think profiles and @profile could help us finding that the sweet spot. I think it should be possible to a) have a look at how namespaces works b) define how one wants to implement them in HTML5 – or what one wants to use from the namespace specification(s) in HTML5 and c) write a document (a profile) in which one specifies a subset/reinterpretation - in other words a profile - of the namespace spesification and then d) refer to this profile when we implement this namespace profile in HTML 5. We don't need to use the @profile if we define it as part of the default profile. -- leif halvard silli
Received on Thursday, 27 September 2007 05:27:46 UTC