W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > July 2009

Re: PROPOSAL from telecon on XMLLiteral

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 28 Jul 2009 01:16:07 -0400
Message-ID: <4A6E8997.4000500@digitalbazaar.com>
To: Jeni Tennison <jeni@jenitennison.com>
CC: RDFa <public-rdf-in-xhtml-tf@w3.org>
Jeni Tennison wrote:
> It really worries me that the TF would make this kind of
> backwards-incompatible change lightly, when it will make existing
> implementations non-compliant and change the interpretation of existing
> RDFa.

Hi Jeni,

Some clarifications. We're not making the decision lightly - it's a
proposal currently that we're considering. However, most of our
(limited) usage feedback and experience is that most XMLLiterals that
are being generated were never intended to be XMLLiterals. I, as well as
our engineers, make this mistake often when embedding RDFa into
auto-generated pages.

In other words, authors are generating XMLLiterals when they don't mean
to generate them. Not many authors even know what constitutes an
XMLLiteral, so making that the default seems like the wrong thing to do
(hindsight being 20/20).

I think that we need more data to back up the argument fully, but if
mistakes are being made on a wide scale now, it would be better to
change the markup to follow use in the field now instead of perpetuating
a large amount of junk data as we move forward.

> It doubly concerns me that the TF would propose interpreting RDFa in
> HTML(4/5) differently from the same RDFa in XHTML 1.1, because detecting
> the difference is not exactly easy for client-side implementations, and
> it makes things harder for servers that are using content negotiation to
> serve the same file as HTML or XHTML (based on reported Content-Type) to
> different clients. Effectively, it will mean the best practice is to
> always supply a datatype attribute in the RDFa markup, just in case an
> XHTML-based RDFa processor parses it, and that is tedious in the extreme.

I don't think we're proposing different interpretations of RDFa in
HTML(4/5) vs. XHTML. Ben was outlining that there may be a number of
months where the specs don't match up, but that would have to do more
with the publishing process than the Task Force's desire. We want to
create a unified mechanism for expressing RDFa across all HTML family
languages. The intent is to interpret XMLLiterals in the same way across
all languages.

> If RDFa is badly designed in how it says we should interpret a missing
> datatype attribute, I'm afraid that it's a mistake that our past selves
> made and that we have to live with. If people are going to build things
> on top of RDFa, they must be reassured that its specification is stable,
> and will not be changed on a whim.
> But that's just my opinion.

It's certainly a very valid concern and we're extremely sensitive to
ensuring that implementers know that RDFa is a stable specification now
and will continue to be so in the future. We would ask for feedback and
guidance from the largest implementers and community to see if this is a
concern for them. If this decision were to happen, it wouldn't happen
lightly, and it would most probably rev the spec (Shane? Steven? Ralph?).

As far as living with our past mistakes - web standards have a history
of attempting to fix issues as they move forward. HTML 2.0, 3.2, 4.0,
4.01, and 5 all attempt to fix issues in the previous versions using
lessons learned from implementation feedback.

Now that you know that we're not taking this change lightly and that we
would ask for community feedback before making the change, do you still
feel as apprehensive about the change as you did before?

If anybody else has any thoughts in favor or against making the default
datatype="" instead of datatype="rdf:XMLLiteral" for child nodes with
non-text node content, please let the community know.

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.1 Released - Browser-based P2P Commerce
Received on Tuesday, 28 July 2009 05:16:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:03 UTC