- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Thu, 12 Nov 2009 21:03:42 +0100
- To: Henri Sivonen <hsivonen@iki.fi>
- CC: Manu Sporny <msporny@digitalbazaar.com>, HTML WG <public-html@w3.org>
Henri Sivonen On 09-11-11 09.23: > On Nov 11, 2009, at 07:55, Manu Sporny wrote: >>>> - Defining the new replacement mechanism for @profile as >>>> rel="profile" >>> What problem does this solve? [...] >> Are there instances where it is not a flaw? For example, when >> processing a page according to Microformats, GRDDL, RDFa >> or DC-HTML rules? > > As I understand it, processing the page as a whole according to RDFa > or Microformat rules isn't a flaw because there aren't competing > extensions using the same syntax as RDFa and Microformats. (Note that > the data expressed as RDFa or Microformats doesn't necessarily apply > to the whole page even though RDFa or Microformat processing is run > over the whole page.) > > If the idea is that @profile should enable other extensions to use the > same syntax as RDFa or Microformats but with incompatible semantics, > then it would be a flaw to apply the same rules to the whole page, yes. You jumped over DC-HTML. Since it was present in the WHATWG developed spec, we discussed predefined class names early on in this WG. Rel values are like class names: Anyone could add their own values. This means that e.g. HTML5 could specify a rel name that is already occupied by someone's use - just as the earlier predefined class names could be occupied with undefined author semantics. To maintain semantics already specified - realizing that the HTMLwg has the power to overwrite any "private" semantics, one could thus point to a profile URI to avoid the overwriting that this WG has the power to make. Though profile of course isn't only for (preventing) writing over semantics, but also for pointing to the semantics of "new" values. > No, I wasn't making either assumption. I was pointing out that one can > adopt any of the following 3 positions and come to the conclusion that > there shouldn't be a rel=profile as drafted: > > 1) Position: @profile a flawed concept. Conclusion: rel=profile is > conceptually the same, hence flawed, too. > 2) Position: Applying @profile to the entire page is flawed. > Conclusion: <link rel=profile> is flawed, too. > 3) Position: @profile is needed for compatibility with existing > specs that use @profile. Conclusion: <link rel=profile> is something > else, so it doesn't satisfy existing specs (without changing the > existing specs, which would make the specs new specs rather than > existing specs). > > My point is that even with some freedom with choosing the premises, > the conclusion is that rel=profile as drafted doesn't help. Would you be more comfortable with HTML5-EPB if it only specified @profile? Would you support a Change Proposal to HTML5 to get @profile back? >> 2. There are a number of communities that have taken issue with >> @profile >> being made obsolete, not because they have nothing better to do, but >> because it affects them and has repercussions on their work. If HTML5 >> got rid of @profile and nobody complained, that would help to prove >> that >> it is a useless feature - however, that has not happened. > > So why are you introducing rel=profile and still obsoleting @profile > instead of writing a Change Proposal to introduce @profile as non- > obsolete? Why don't you ask why Ian expressed that GRDDL etc should use rel="profile" instead of @profile? Therein lays the reasons for why HTML-EPB specifies rel="profile", AFAIU. I would be very interested in knowing Ian's justification. May be he simply wants to align the extension points - a draconian "purity" standpoint. Or may be he really thinks there is a feature difference. Or may be something else. -- leif halvard silli
Received on Thursday, 12 November 2009 20:04:17 UTC