[whatwg] Trying to work out the problems solved by RDFa
Calogero Alex Baldacchino
alex.baldacchino at email.it
Tue Feb 3 19:16:05 PST 2009
Toby A Inkster ha scritto:
> Another reason the Microformat experience suggests new attributes are
> needed for semantics is the overloading of an attribute (class)
> previously mainly used for private convention so that it is now used
> for public consumption.
Maybe this is true, but, personally, I prefere this approach to the
addition of new features/attributes/elements to an official
specification without a clear support requirement for UAs beside just
parsing. A similar (if not stronger) argument may be raised against the
reuse of the content attribute in the context of RDFa, which I think has
caused a significant change with respect to its original semantics (now
it should be shared by every element, originally it was a <meta>
specific attribute; now it should be part of an RDF _triple_, in origin
it was - and is still - part of a _pair_ when used in conjunction with
the "name" attribute, and constitutes a pragma directive in conjunction
with the "http-equiv" attribute, which is somehow closer to an XML
processing instruction than to an RDF triple - the same applies to a
<link> with rel="stylesheet", for instance).
> Yes, in real life, there are pages that use class="vcard" for things
> other than encoding hCard. (They mostly use it for linking to VCF
> files.) Incredibly, I've even come across pages that use class="vcard"
> for non-hCard uses, *and* hCard - yes, on the same page! As the
> Microformat/POSHformat space becomes more crowded, accidental
> collisions in class names become ever more likely.
Indeed, that's a possible source of troubles. I think that's the same if
people misused prefixes, e.g. if after merging some content from
different documents they got a different namespace binded to a
previously declared prefix in a scope where both namespaces are involved
(in an xhtml document). Also, a custom script may distinguish between
different uses of "vcard" by the mean of a further, private classname,
or by enveloping elements in containers (divs) with proper ids, which
may be a good solution in some cases, and not in other ones; a more
generic parser, being specialized by design, has a chance to recognize a
correct structure for a given format and to discard wrong informations,
which may work fine in some cases, but not in others. As always, each
choice has its own downsides, and what counts is the costs/benefits
ratio; it seems that any solution not requiring to be supported has the
lowest costs for UA implementors.
I do not doubt xml extensibility (which effectively is the base of
curies) has its own benefits, it's flexible and suitable for a quick
developement of custom solutions, but it's also got its own downsides,
such as leading to a possible heavy fragmentation, being difficoult to
understand and use for many people (who are usually fooled by the
concept of namespaces) and thus potentially causing misuses and errors.
It doesn't seems that xml extensibility brought more benefits than
costs, and a proof can lay in the majority of the web not having
followed the envisioned xml-alike evolution.
Anyway, I'm not strongly against RDFa in HTML, instead, I can be quite
neutral (I'd live with it); I'm not convinced it is worth to add it to
the spec at this stage and until it would be possible to establish what
UAs must do with them beside parsing (and how to deal with namespaces
while parsing). Also, I'm not fully convinced by the need to embed
metadata in a page and keep them in sync with that page. For instance,
it require that every page reporting the same informations must
duplicate the same metadata structure, and this doesn't grant that those
informations, in first place, are in sync with real world (some pages
might be out-of-date, others might be up-to-date). Instead, a separate
file containing metadata to be linked when appropriate might solve both
the problems: it doesn't require duplicates and can have a somewhat
versioning to keep trace of changes and to present updated
machine-friendly information to help users visiting an outdated page
(assuming users can trust those metadata). Of course, this solution has
its own downsides too.
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
Blu American Express: gratuita a vita!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8615&d=4-2
More information about the whatwg