Raw

There appears to be a significant contingent of the HTML5 group in favour of dropping the profile attribute which appears in HTML 4.

The arguments against dropping it generally revolve around the idea that this would disempower authors and publishers. There are at least two aspects to this: firstly by using a profile the producer of a document is authorising specific interpretation(s) of that document. This is markedly different from the consumer of the document scraping the markup and making their own assumptions about what was intended. Secondly if a group decides a particular (non-URI) string should be interpreted in a given fashion, it in effect dictates how the world should use it. It's squatting the commons. Someone expressed this recently as " URI-based extensibility vs. picking short names and flying around the world promoting them".

The primary argument in favour of dropping @profile is: " basically nobody uses profile".

There are a lot of factors which will determine the decision of the group, which probably all come under the umbrellas of people, principles and process. Before it gets to head counts and admin, whether an argument like " nobody uses profile" holds any sway depends to a large extent on what princples the members of the group subscribe to. To drop in halfway through this IRC discussion on #html-wg, Hixie says:

this is why we should agree on the principles first. not having profile="" is very much an application of the Pave The Cowpaths principle.

As a guiding principle, Pave the Cowpaths makes sense. Practices that have already been adopted organically are those likely to best most suitable for enshrining in specifications, as they already are standards.

I stress as a guiding principle because the utility of this principle depends on how candidate Cowpaths are determined, and whether the paving of them will render other potential paths impassable.

Ok, I'm largely motivated to talk about this because of GRDDL which relies on @profile in XHTML documents (other mechanisms are available for other XML dialects). This is a new spec, not even at Rec. status yet. To treat the rarity of the @profile in the wild as a Cowpath and drop it from HTML5 at this point in time could be a major hindrance to the GRDDL path in future. On this argument my suggestion would be to give GRDDL a few years, then look again at dropping the attribute, if it still seems appropriate.

Put another way, how do the relative benefits of Paving vs. not Paving compare, or probably more significantly the balance of harm caused by maintaining this (optional) attribute compare with the harm of removing it? We can't say for certain whether use of @profile will increase in future now that GRDDL makes it that much more useful. We can say for certain that if @profile goes, this avenue will be closed. It goes far beyond being an application of the paving principle.

I think this line of argument is valid, but don't personally see it as the strongest rationale in favour of keeping the profile attribute. That I believe is related to how candidate Cowpaths are determined. In this case I'd suggest the folks arguing for the dropping of @profile are taking too narrow a view, not seeing the forest for the trees.

HTML is intended for the Web. Irrespective of architectural astronautics, what makes the Web the Web is the link. @profile is a link that allows the agent to get more information about the current document than can be expressed in HTML core. (If you want the astronautics, the link is a HTTP-resolvable URI which allows the agent to get more data from representations of the identified URI. The profile attribute is a neat WebArch-friendly use of the URI to provide an extension point).

Ok, to date this particular kind of link has been little used, though currently the path is clear, if not well trodden. But @profile a link, and given the importance of the link in general, to block any kind seems risky, if not irresponsible.

But now stand back and forget the specifics, the link is the Cowpath leading from one piece of information to another. Pave that. 

 

@en