Re: thoughts on @profile (ISSUE-55)

Julian Reschke On 09-05-21 16.49:
> (1) Syntax (1/2)
>
> The @profile attribute is underspecified in HTML 4.01; there is 
> disagreement whether the ability to specify multiple profile URIs is 
> legal syntactically, and whether "additional" profiles carry any meaning.
>
> That has led to the unfortunate situation where TIDY-based validators 
> (such as <http://users.skynet.be/mgueury/mozilla/>) report multiple 
> URIs in @profile as error (see 
> <http://sourceforge.net/tracker/index.php?func=detail&aid=1264455&group_id=27659&atid=390963>) 
>
>
> This problem IMHO should be fixed as erratum to HTML 4.01. Does that 
> fall into our charter?

Björn Höhrmann's argument for not fixing the HTML Tidy bug is that HTML 
4.01 says "profile = uri [CT]", hence it must be meant "a single URI", 
despite the fact the text of the following sentence directly says that 
@profile may be contain several URIs. The issue was also debated in the 
www-html list in 2006 [1], because Björn pointed out that the XHTML 
working group, due some thought about using @profile as a identifier for 
compound documents, had limited the @profile to only take one URI! Björn 
then pointed to the HTML 4 DTD and claimed that @profile always had been 
limited to one URI:

     profile     %URI;          #IMPLIED  -- named dictionary of meta 
info --

Ian, in the same thread, replied that in HTML 5, several profiles was 
allowed [2]. Tantek then explained that the prose of the specification 
trumps the DTD (as DTD cannot express everything that is possible) [3]. 
Björn H. repeated (amongst other things) his profile standpoint in 
"Spidermann and the XHTML Kindergarten" last week [4]. And  - regarding 
our charter: the follow-ups from Philippe and Tim B. L. show that the W3 
are taking the issues Björn took up last week seriously and that they 
are also are looking for feedback from the HTML working group on the 
issues. [5][6]

An errata that satisfies Björn H. would need an update of the DTD. The 
fix would probably have to take "idrefs" (list of idref tokens) as 
pattern and introduce "uris" (list of URIs) as one of the Basic HTML 
data type in the DTD. Is that how you see it as well, Julian?

> (2) Syntax (2/2)
>
> Many have pointed out that it makes more sense to expose a profile as 
> a link relation with @rel="profile". I think this is a good idea, 
> although issue (1) should be resolved nevertheless so that there is a 
> transition period.
In case of an HTML 4 errata, why not also update HTML 4 with the 
@rel="profile" as well? Such a thing could even be done /without/ any 
DTD change.


Also, regarding the exact syntax, and since you mention namespaces 
below: It has been pointed out that namespace declarations creates 
warnings in HTML 4 validators.[7] Whereas adding a new @rel value does 
not do that. So how about introducing namespaces for profiles? E.g. like 
this:

    <link rel="profile xmlns:curie" href="profileURI">? 

Or even like this:

    <link rel="profile:curie" href="profileURI">.

After all, RDFa attribute values represents meta data. It seems logical 
- and perfectly in line with HTML 4 - to link the meta data to a profile 
instead of a namespace. A namespace represents another markup language 
with its own meta data profile. But since, in the case of RDFa in  HTML 
5, it is only the meta data profile we are after, then why declare a 
namespace? It ought to be enough to limit the entire thing to a "CURIE 
declaration" for the profile ...

(It seems to me that the way RDFa implements namespaces and profile 
perhaps bear some traces of the willingness to limit @profile to just 
one URI back in 2006.)

> (3) Dependencies from other specifications
>
> There are currently several specifications that require @profile, such as
>
> a) GRDDL (W3C)
> b) DC-in-HTML (DublinCore)
> c) Several microformats (microformats.org)

RDFa supports in HTML may require @profile as well. E.g. Shane 
McCarron's "RDFa in HTML". [7]. Although it is (currently) only used for 
linking in the "XHTML Vocabulary" profile [8]

> If we believe that using link/@profile='rel' is a good solution then 
> we should talk to these people and see whether they are willing to 
> update their specs accordingly (I understand that many in the 
> microformats community do not care about @profile at all, but in that 
> case they need encouragement to update their documentation).
>
> (4) Format of a "profile document"
>
> As far as I can tell, profile URIs are just like XML namespace URIs: 
> the spec does not require them to be dereferenceable; clients are not 
> required to dereference them, and there is no standard document format 
> for them. (Are they Information Resources? /me ducks)

I think we can say at least the same, and probably some more than HTML 4 
about this:

- a profile is typically a HTML page.

- a profile page should inform about the official profile uri of the 
profile. (Certain profiles, such as eRDF 
(http://purl.org/NET/erdf/profile), uses a PURL url as its profile URI. 
The profile page URI and the profile URI will then differ. Also some 
profiles contains many pages - e.g. the microformats profiles, and it 
can be hard to see figure out what the profile URI of e.g. hCard is. The 
DC profile for HTML/XHTML pages, however is tells this very clearly)

- profile pages are meta data dictionaries - they inform about the 
meaning and use of the vocabulary they introduce.

- amongst others GRDDL has introduced profiles were implementations look 
at the URI(s) of <link> or <a> elements with particular @rel values and 
then perform actions based on what the documents at those URIs tells 
them. (This, again, hints that profile pages should per see be 
informational, but that they may contain semantic HTML that allows 
"machine action".

- GRDDL also wants that profiles are made GRDDL compatible - which 
requires use of the profiles and/or @rel values that GRDDL needs. This 
represent some kind of format, you could say. (The Dublin Core profile 
is now GRDDL compatible[9].)

- It seems like implementations must be taught the meaning of the linked 
in vocabularies. But that when they know their meaning, they may use 
them to act upon - e.g. an GRDDL implementation will act on this, 
because it already  knows the meaning of "rel='transformation'":  <link 
rel="transformation" href="http://www.w3.org/2003/g/glean-profile" />

> (5) Not breaking other specifications
>
> Unless there's a technical reason why this needs to be done, HTML5 
> should not break other specs, in that what they say doesn't work for 
> HTML5 anymore -- which is the current situation. Therefore, I think 
> HTML5 should re-introduce head/@profile and make it valid, even though 
> there may be better approaches, such as link/@rel=profile. I would 
> support HTML5 defining the "profile" link relation, and having 
> language that recommends using link/rel=profile over head/@profile in 
> new specifications.
Regarding not breaking other specifications, then HTML 5 also needs to 
support @rev, even if HTML 5 itself does not embed a meta data profile 
that makes any use of @rev. (Both HTML 4 and HTML 5 has a default meta 
data profile.) E.g. in RDFa @rev is used because:

   "Having just one term to describe the relationship,
    and reversing the direction by moving it from @rel 
    to @rev, makes vocabularies smaller and simpler." [10]

Thus, to not support @rev, would mean that - unless the vocabulary is 
extended to take care of HTML 5 specifically, the lack of @rev would 
make it  impossible to express the same RDFa things in HTML 5 as in XHTML.


(6) I would also suggest a 6th subject: Purpose of the profile URI

I think that the previous rejection of @profile by the WHATwg was very 
much based on the view that "but it doesn't have any effect in regular 
UAs". And in general, the confusion about the purpose seem greater than 
the confusion about how many URIs @profile might take.

Is the purpose to link to a page that documents the attribute vocabulary 
that this page uses? ("Information Resources", as you wrote. Information 
for humans, then.) Is it a "tag" for authors and reviewers so they can 
see what vocabulary the page is using? Is it something that UAs are 
supposed to act on? Is the purpose to be able to validate the page 
according to the profile used? Is the purpose to give tools or UAs the 
opportunity to treat the document in a certain way due based on 
pre-knowledge about how to act when seeing a particular profile URI? Is 
the purpose to take advantage of XHTML Modularization? (The before 
mentioned "XHTML Vocabulary" - footnote 8 - makes available a vocabulary 
that is needed for RDFa implementations when they read the @rel/@rev 
values of RDFa enabled page.)

[1] http://lists.w3.org/Archives/Public/www-html/2006Feb/0087
[2] http://lists.w3.org/Archives/Public/www-html/2006Feb/0088
[3] http://lists.w3.org/Archives/Public/www-html/2006Feb/0095
[4] http://lists.w3.org/Archives/Public/www-archive/2009May/0029
[5] http://lists.w3.org/Archives/Public/www-archive/2009May/0038
[6] http://lists.w3.org/Archives/Public/www-archive/2009May/0045
[7] http://www3.aptest.com/standards/rdfa-html/
[8] http://www.w3.org/1999/xhtml/vocab/
[9] http://dublincore.org/documents/dc-html/
[10] 
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019867.html
-- 
leif halvard silli

Received on Friday, 22 May 2009 06:49:44 UTC