Re: FPWD Review Request: HTML+RDFa

Hi Sam,

> The "layering" concern is an equally simple point.

It wouldn't be the first time that I've failed to grasp a simple
point, so perhaps you could help me out here.

Would you mind clarifying what exactly the 'concern' is? Is it that
W3C spec's aren't being reused?


> People who "layer" their
> applications on top of libraries (in other words: simply use such libraries)
> based on the same standards that you referenced will often have namespaces
> transparently "taken care of" for them.  And sometimes this will make their
> job harder.

Now this is where I start to get lost. RDFa doesn't actually 'use
namespaces' any more than it uses @href. So the metaphor of simply
incorporating a library, unaltered, doesn't help us here. With
namespaces there is no "taken care of" to be taken care of.

Of course, if an XML DOM automatically mapped our CURIEs for us -- to
make up an example for illustrative purposes -- so that we didn't have
to do anything clever with strings like "dc:creator", then you could
say that there is some aspect of layering that we are not taking
advantage of. And you might rightly say then, that processing would be
different in an XML-aware DOM than in a non-XML--aware DOM (i.e., a
DOM Level 1 DOM).

But there really isn't anything that an RDFa parser gets help with,
when running on DOM2, over and above what is obtainable from DOM1. But
it's more than that; this isn't just me hiding behind weaknesses in
the DOM API -- there really is nothing in RDFa at the markup or
processing level either, that requires 'proper' namespace support.


> I'm not suggesting that you change anything.  I'm just trying to explain the
> point that is being made.

But if I may say, you seem to think that the only reason I could be
disagreeing is because I don't understand.

I do understand...and I disagree. :)


> Saying that RDFa could have chosen a different
> syntax misses that point.

Not really. It was to show that the *only* thing we are taking from
XML Namespaces is the syntax. For example, we're not relying on an XML
infoset. And as I said above, we're not relying on any DOM2 feature,
either.


> The two possible resolutions I see here are:
>
> (1) All things considered, we'd like to keep with the xmlns: syntax, warts
> and all.
> (2) Upon further consideration, we'd like to change the syntax to avoid
> these problems.

You're effectively saying that supporting a new prefix syntax, implies
that there is a "problem" with using xmlns-based attributes.

If by "problems" you mean the "layering problem", then I have to
restate that it doesn't exist since RDFa does not use XML Namespaces
'as such'.

And if by "problems" you mean the "some-people-don't-like-namespaces
problem", then yes, that view does exist -- and it's represented
within the RDFa TF as well as outside it. But it's a problem for
another day.

Today's problem is to reassure people who are currently putting RDFa
into HTML4 and XHTML that they'll easily be able to migrate to HTML5
in the future, and preserve their investment. And that means keeping
the xmlns-based attribute technique, even if we build on it in the
future.

If I may, to hopefully make my point a little clearer, and show how it
relates directly to this discussion, I'd like to rephrase your
resolutions. I would say instead:

(1) All things considered, we *need* to keep with the xmlns: syntax,
warts and all, *because that's what people are doing now in HTML4 and
XHTML*.

(2) *We've always known* that we'd like to *enhance* the syntax *with
something that makes no reference to @xmlns, but that is something we
would have to do in another version of RDFa*.

Note that posed this way, the two 'resolutions' are not mutually exclusive.

Regards,

Mark

-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Friday, 4 September 2009 09:31:44 UTC