Re: PROPOSAL from telecon on XMLLiteral

Manu,

I try to understand one aspect of the proposal. Is it so that

<div datatype="" property="a:b">XML CONTENT</div>

and

<div property="a:b">XML CONTENT</div>

would have the same effect? Ie, to produce an XML Literal, I have to
explicitly define it with the datatype?

We gave a special role to the @datatype="" in this respect and I think
it is essential to keep that. Indeed, there are a number of RDFa
deployments out there that make use of that trick to _avoid_ generating
XML Literals and we do not want to spoil that. In other words,
@datatype="" would still be valid with the same effect, it would just
become unnecessary.

With that we would probably make most of the RDFa content stay valid and
unchanged. Maybe it is worth 'asking it around' among RDFa deployments
to see if _real_ XML Literals are used frequently or not, to get a
feeling of the possible damage such a change would produce (I am not too
afraid of implementers, for those this change should be doable easily
and quickly)

Ivan

Manu Sporny wrote:
> 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
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf