Re: thoughts on @profile (ISSUE-55)

Leif Halvard Silli wrote:
> 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 

Interesting. Is this reflected in a *published* recommendation somewhere?

> 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]. 

For once, I agree with Ian and Tantek.

> 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]

I appreciate that Björn insists on doing the right thing, and that his 
email has caused people to look closer at what's going on.

> 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?

Exactly.

> 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">?

RFC 2731 (<http://greenbytes.de/tech/webdav/rfc2731.html>) and DC-HTML 
(<http://dublincore.org/documents/dc-html/>) already define a different 
syntax for that; so; *if* we wanted to do that, we should consider just 
using that.

> 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 ...

In recent discussions, the RDFa people claimed that non-registered link 
relations did not work in HTML 4.01 unless qualified by a profile; if 
there was agreement about that, RDFa would need that as well because of 
the use of CURIEs.

> ...
> 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.
 > ...

Agreed, but that's a separate issue. (pick your battles...)

> ...

BR, Julian

Received on Friday, 22 May 2009 12:55:38 UTC