Re: @rel syntax in RDFa (relevant to ISSUE-60 discussion), was: Using XMLNS in link/@rel

On Mar 1, 2009, at 18:25, Ben Adida wrote:

> Henri Sivonen wrote:
>> the assumption that new work would all be XML-based.
>
> And our work is entirely XML-based to date. But the RDFa Task Force is
> joint with the Semantic Web Deployment working group, which itself has
> an interest in seeing RDFa adopted more widely.

If you have an interest in deploying it more widely, perhaps it would  
make sense to design for wider deployment instead of designing for XML  
only.

>> We now know that the demise of text/html was greatly exaggerated, so
>> it's now necessary to evolve HTML and XHTML in such a way that a  
>> unified
>> vocabulary works with both text/html and application/xhtml+xml.  
>> Hence,
>> previous XML-only bets were misplaced. That's tough, but things  
>> need to
>> be adjusted for the dual serialization situation.
>
> I agree with that, which is why we're seriously considering the  
> @prefix
> change, but I disagree with your approach, which appears to be more
> about "change for the sake of change", or at least change to fit an  
> HTML
> world view which is empirically incorrect.

My view is "empirically incorrect" only if you do your empirical  
studies with namespace-unaware APIs, such as DOM Level 1. I would  
expect layering new specs directly on top of XML 1.0 and yanking  
Namespaces out of the stack to be an Architectural no-no at the W3C.  
Certainly, it's a practical no-no considering reusing software that  
has been written with the assumption that XML vocabularies are layered  
on top of XML 1.0 + Namespaces rather than XML 1.0 only.

I'm not suggesting change for the sake of change. My interest here is  
keeping things so that text/html and application/xhtml+xml can be  
consumed with a single namespace-aware application-layer code path  
using the infoset representation API of the application developer's  
choice given a conforming XML+Namespaces parser for that API and a  
conforming HTML for that API. That is, I'm interested in keeping the  
software architecture for consuming applications sane. I think  
language design that implies bad software architecture can't be good  
Web Architecture. The single code path architecture also precludes  
taking branches on version identifiers and such.

Concretely, given the software architecture of Validator.nu (which is  
SAX2-based and pretty good architecture in the absence of RDFa), I  
couldn't add RDFa validation with the xmlns:foo syntax without either:
  1) Resorting to bad software architecture by implementing notably  
different above-parser code paths for text/html and XML.
OR
  2) Changing text/html parsing to map xmlns:foo to infoset  
differently from how already shipped Gecko, Opera and WebKit have  
mapped xmlns:foo in text/html to infoset (by considering how they map  
to DOM Level 2 and then by applying the DOM Level 3 to infoset mapping).

I think browsers and non-browser data mining tools should use the same  
text/html to infoset mappings (and XML to infoset mappings) and  
language design assuming different infoset mappings in different  
classes of products would be bad Web Architecture.

I think new stuff recommended for deployment in both text/html and  
application/xhtml+xml should presumptively stay away from the  
syntactic areas where XML 1.0 + Namespaces mapping to infoset and  
existing text/html mapping to infoset for a given piece of syntax  
differs. It's better to just stay away from that area than to try to  
prove that a change to the infoset mappings in that area wouldn't  
break anything if deployed in browsers.

(Sometimes a change has such a high reward that it's worth trying  
though. I think adding SVG support to text/html is such a case. I  
don't think RDFa is such a case. More to the point, SVG is truly  
pre-2004 legacy while RDFa is not and, therefore, it is somewhat  
excusable that SVG wasn't designed with text/html compatibility from  
the outset.)

Note that the concern is about software architecture for consuming  
applications. It isn't about whether RDFa is blessed as valid by the  
HTML5 spec. It isn't about whether stuff served as text/html is called  
XHTML+RDFa or something else.

>>> So I don't think we did anything rogue
>>
>> Yet, when RDFa is deployed in
>> text/html, community sites like rdfa.info cheer[2].
>
> And when HTML5 features are deployed in browsers before they're
> standardized and while many other folks are howling, is the HTML5
> community not happy?

The HTML5 community tends to cheer when people deploy drafted HTML5  
*as drafted*. For example, HTML 5 does draft <video> for both text/ 
html and application/xhtml+xml. This is in contrast to speccing stuff  
for only one those two but cheering for deployment in the other.

> If anything, the fact that RDFa is being successfully deployed in HTML
> should make many of your arguments moot, but you continue to fight  
> this
> battle where the only good deployments are the ones that comply with
> your view of the world.

Actually, if RDFa with its current syntax "succeeds" in text/html, I  
think the issue I'm concerned about will be hit sooner or later. If  
RDFa in text/html fails so that no one wants to implement consuming  
software for it with namespace-wise correct tools, then my point will  
be moot.

> You're right on this point, but again that doesn't mean change for the
> sake of change is a good idea. HTML5 doesn't *have* to leave its  
> mark on
> everything just for the sake of it.

Like I said above, I'm not interested in leaving an HTML5 mark on  
anything. I'm interested in keeping software architecture sane for  
apps that consume both text/html and application/xhtml+xml using  
namespace and infoset-wise correct development practices.

> I believe it is rather arbitrary and in conflict with existing uses in
> HTML4. First, the use of IRIs in @rel is *quite* new, I know of no  
> major
> (or even minor) vocabulary that's deployed this way.

I'd be OK with URIs, but I'd expect i18n core to object.

> Rather, Dublin Core suggests a prefix-like approach: dc.title,
> dc.creator, etc... OpenID does the same thing. eRDF does the same  
> thing
> *and* uses indirection to define its prefixes.

So why doesn't CC+ use cc.foo? Why doesn't CC+ use eRDF?

> And finally, microformats suggest using @profile to interpret their
> @rel's and @class's.

But this isn't how microformats work in practice.

> And, as I just explained in my email to mnot, existing W3C RECs that
> *do* function on text/html, e.g. GRDDL and eRDF, use @profile to alter
> the meaning of @rel via a level of indirection.

GRDDL uses profile for two distinct things:
  1) to authorize rel=transformation to be recognized
  2) to dereference for transformation autodiscovery via profile  
documents that may or may not link to a transformation.

Point #1 can be addressed by a spec such as text/html authorizing  
rel=trasformation to be recognized as a well-known token without  
profile (i.e. making the processing similar to rel=next or  
rel=canonical).

I think point #2 (i.e. following your nose with canonical URIs) is a  
design bug due to the scalability problems demonstrated already by DTD  
URIs even though DTD URIs in theory aren't URIs-as-identifiers but  
URIs-as-locators.
http://hsivonen.iki.fi/no-dtd/

> Given the way HTML4 is *already* used with @profile and @rel values,
> RDFa's approach doesn't introduce additional cost.

HTML4 only uses profile in theory. I'm interested in compatibility  
with text/html rel as it has been practiced prior to RDFa.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 2 March 2009 09:24:37 UTC