RDFa in XHTML Task Force

 

Action Items

<scribe> ACTION: Ben to query the RDFa TF and ML to gather feedback regarding the XMLLiteral default for @datatype [recorded in http://www.w3.org/2009/07/23-rdfa-minutes.html#action02] [DONE]

<scribe> ACTION: Ben to author wiki page with charter template for RDFa IG. Manu to provide support where needed. [recorded in http://www.w3.org/2009/05/28-rdfa-minutes.html#action10] [CONTINUES]

Ben: Did a little bit of work on that
... We should wrap it up - we have enough support now.

Manu: Time frame?
... HTML WG will have LC on HTML5 in Oct. There are some dependencies between RDFa IG and HTML5+RDFa now.

Ben: Would like to get it started at first point in August.
... We need to structure it so that it's easy for the W3C to accept the RDFa IG. RDFa isn't controversial, so shouldn't be an issue.

XML Literals (thoughts)

Ben: Not much feedback, would it warrant versioning?

Shane: Yes, absolutely it would.

Ben: What if it's a matter-of-fact? Google and Yahoo want the change.

Shane: Doesn't matter, we need to change the language identifier.
... This is exactly why languages need version specifiers.

Ben: yes, but changes are so minor.

Shane: Yes, but this isn't an errata - even if nobody has used the feature, it's an incompatible change, and thus we need to increment the version number and go to LC.

Manu: I agree with Shane and the ghost of Ralph (who would say the same) in this situation.
... We're going to have to bump revision numbers at some point.

Ben: Yes, maybe - but we have to go through LC.

Shane: We've been talking about releasing the XML Schema version
... We will have to do a proposed edited REC, but not go through LC for that.

Ben: That has no backwards-incompatible changes, right?

Shane: Yes and we don't have to change the version numbers.
... You still have to do all the issue tracker, disposition of comments, diff-marked, etc.

Ben: but if you re-open backwards-incompatible changes, the scope you have to address is wider.

Shane: Yes. XMLLiteral would trigger a new version of the spec.

HTML5+RDFa FPWD proposal and xmlns: language change

<benadida> ACTION: Shane to produce proposed diff re: XMLLiteral change [recorded in http://www.w3.org/2009/07/30-rdfa-minutes.html#action03]

<benadida> Manu: LarryM (Adobe) has proposed that all 3 current HTML5 specs be simultaneously published for heartbeat

<benadida> ... they don't care deeply about RDFa, but want a process for alternate specs.

<benadida> ... Maciej doesn't want to hold up Ian's version

<benadida> ... SamRuby wants 3 people (not in RDFa community, voting as a block) to support the HTML5+RDFa spec.

Ben: I will respond on HTML WG and look at the thread
... What about xmlns: language?

Manu: It doesn't state anywhere in the HTML5 spec, that I can tell, that preserves "invalid" attributes in the DOM in (non-xml) mode .
... it affects firebug, facebook, etc.

Ben: It also affects Dojo.

Shane: There is a difference between xml mode and non-xml mode.
... In non-xml mode, literals are preserved (with some weird thing about colons), but in xml mode, they are not preserved
... since it doesn't go into the NULL namespace, it goes into the xmlns namespace
... You can't find it because the literal isn't there anymore.

Ben: xmlns: must be supported in XHTML5.

Shane: That already works.

Ben: Then why can't the HTML5 DOM support at least the xmlns: attribute.
... Why are we special casing?
... xmlns: is part of the way things have always been done.

Shane: This isn't hard to do, please do push that argument on HTML WG.

Ben: There is also the an issue that Ian gets to CTR, but others can't.

Manu: Yes, there are two approaches here. One is that Ian CTR'ed to produce the W3C HTML5 WD, so anybody else
... should get the same rights if HTML WG is going to operate under CTR. The second approach is that there is enough
... "independent", as Sam Ruby put it, interest that this isn't an issue. In both approaches, we still need language in the
... HTML5 specification to ensure preservation of xmlns: in non-xml mode in HTML5.

@profile discussion

Ben: Trying not to become more extremist about this, but it's making me worried.

Manu: Have you seen my latest e-mail about "we're doing the same work with both approaches"?

Ben: Yes, but what we're dealing with is vocabularies that will bootstrap on other vocabularies.
... So, http://google.com/vocab#title becomes the de-factor instead of http://dcterms.org/terms/title
... It rules out Javascript parsers...
... It must take on a big scope that most parsers take on - security implications.
... Dereferencing third party websites is problematic.
... In Mark's proposal, there's no step-wise approach. It's all or nothing.

Manu: I think you have good points re: security and re: Javascript parsers being impossible with Mark's proposal.
... I think you may have just convinced me that we can't do Mark's proposal.

Shane: Yes, those are deal-breakers for me.

Ben: With the current approach, XSS makes it impossible.

Shane: My sense with your proposal is that it doesn't have much to do with RDFa.

Ben: With my proposal, I need the ability to set the default CURIE prefix, which I can't do.

<benadida> ACTION: Ben to summarize architectural issues (security) re: @profile proposal for tokenizing the web. [recorded in http://www.w3.org/2009/07/30-rdfa-minutes.html#action04]