RDF in XHTML Task Force

Ben: See the xmlns:* post I made?

Manu: Does it duplicate the same test we did 2 months ago?

Ben: Maybe, but this works now (and it wasn't working before)

Manu: Can we add this to the agenda: http://lists.w3.org/Archives/Public/public-html/2009Sep/0959.html

Action Items

<scribe> ACTION: Ben to update JS xmlns getter code on implementors' guide for xhtml mime type support [recorded in http://www.w3.org/2009/09/17-rdfa-minutes.html#action02] [DONE]

ISSUE-239: errata text to clarify CURIE context

<benadida> proposal text from Shane --> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Sep/0277.html

Ben: Jeni had some issues and Shane wrote some errata text to cover these issues.

Manu: #6 should we say something about xmlns specifically? Or just refer to the XML Namespaces spec.

Ivan: What about uppercase vs non-uppercase?

Shane: We already have an errata item for that.

<Zakim> markbirbeck, you wanted to say that Jeni also suggested that developers might assume that prefixes are already defined for 'xmlns' and 'xml'.

Mark: Jeni also raised the question if there should already be a prefix mapping for xmlns and xml
... It's worth considering.
... If you think of it in the case of namespaces, it's important.
... It's not a straighforward issue, but there is an argument that those two should be there by default.

Shane: That would change the spec, don't know if we can do that in an errata
... For example, it would affect XMLLiterals.

Mark: I don't think so - xmlns and xml are included by default in the XML pipeline.
... We say that it's initialized empty, but in a way it should be initialized with xmlns and xml.

Shane: Ah, it's not legal to declare xmlns and xml.
... ah yes, catch-22.
... ok

Ben: So, Mark - you are saying it should be initialized with xml and xmlns.
... So, it's not just an errata - it could change the conformance.

Mark: I don't know if it would change conformance criteria...

Ben: I think this has to be a part of the 1.1 rev.

Mark: Couldn't we do some of this in HTML+RDFa spec?

Ben: We run the risk of duplicating rules, probably not a good idea.

<ShaneM> Remember that there is room for an RDFa Syntax 1.0 Second Edition AND room for RDFa Syntax version 1.1

Ivan: My impression is that HTML5 progress is slow, we might be able to get an RDFa 1.1 out before HTML5 goes to CR.
... Let's cross the bridge when we get there.

Mark: Why not put this into RDFa 1.1 and publish that and reference that from HTML+RDFa?

Ben: I think we are doing that, we're moving forward in parallel.

Mark: Is there an RDFa 1.1 document right now? Why don't we start working on an RDFa 1.1 version.
... The problems we're solving for HTML5 should also go in RDFa 1.1

Ben: So we're talking about a large encompassing document?

Mark: So we integrate HTML+RDFa into RDFa Core 1.1
... and add some new things for RDFa Core 1.1

Ben: Worried about how this might be perceived - should we start writing RDFa Core 1.1 while working on HTML+RDFa and doing errata for XHTML+RDFa?
... We should be very diligent in working with HTML WG.
... Point #5 - can you not use reserved words in @property and etc.

Mark: We can loosen that restriction in RDFa Core 1.1

Ben: This doesn't change what the spec says?

Shane: Yes, it just gathers what the document already says.

<ShaneM> http://www.w3.org/MarkUp/2008/REC-rdfa-syntax-20081014-errata/Overview.html

Ben: Anybody want more time to review this?

<ShaneM> +1

<ivan> +1

<markbirbeck> +1

+1 for passing this as an errata

<Steven> +1

Mark: So, this isn't a correction?

Steven: No, it can be clarification as well

<benadida> RESOLUTION ISSUE-239 is resolved as proposed by Shane

Adding Precision for DOM Level 2 and Infoset-based processing models

Manu: convo with Henri, working to understand the xmlns DOM issue.
... actually a technical issue. implementation issue in infoset parsers.

<msporny> http://lists.w3.org/Archives/Public/www-archive/2009Sep/0058.html

Manu: working with Philip to integrate his tests.
... straight-forward, no need to discuss at length.
... Henri's issue: XHTML and HTML docs go through diff tool chains, no issue with XHTML docs in HTML5 toolchain.
... browsers are moving towards namespace-aware infoset models.
... with very specific APIs.
... but when we're parsing an HTML doc in non-XML mode, there is a problem.
... with infoset-based parsers, what happens to attributes xmlns:*?
... infoset-based parsers do not have a DOM Level 1 interface, attributes on a node.
... with XHTML docs, straight-forward, just use namespace lookup
... but with HTML mode infoset doc, no namespaces.
... 'xmlns:foo' has been changed to some other string in the null namespace.
... Henri and Jonas say that 'xmlns:*' is destroyed.
... this is specified in the HTML5 spec.

Steven: same bit of spec that i was complaining about?

Manu: yes.

Mark: just to be clear, this is something that HTML5 itself has defined.

Manu: because that's how the parsers work.
... they munge up the names.
... not something that was made up.
... makes sense that they did it this way, because HTML nothing to do with XML.

Ben: but why munge the string?

Manu: internal model is infoset based.
... we could say that this needs to be changed.
... then we have to make a case to vendors.

Steven: so why does it work now?

Manu: because they've layered the DOM layer on top of the infoset+internal model.
... but they like working with DOM Level 2 internally. Others like working with a clean Infoset-based API - like lxml and the html5lib parser.

<Zakim> ShaneM, you wanted to ask about infoset parsing

Shane: appreciate that internally they're doing something to the string, but why do they or we care?
... this isn't exposed anywhere, is it?

Manu: the problem is exposed in lxml parser and html5lib.

Steven: browsers are intent on dealing with existing content. How could they possibly change the behavior of this?

Manu: deal with existing content just fine.
... they don't have any namespaces.

<Zakim> need, you wanted to talk about Infoset issues

Manu: it's very important implementation guidance.
... Henri wants us to change the behavior of the coercion-to-infoset rules to actually create the namespaces.
... so that both in HTML and XML modes, that namespaces are defined.
... the solution is exactly what we want to see happen.
... Henri says that coercion-to-infoset should create namespaces.

Ivan: is there any chance that this will happen?

Manu: The mailing list discussions were misleading...

Mark: not true, it's described *as if* it's a DOM.
... at moment independent of any structure.
... we have to be careful because there's a difference between writing "how to implement" and writing a spec that is general enough for implementation in the future.
... correct to ask "anything more than implementation guidance?"
... if we can smooth the path, definitely, but as Ivan says, can we really see this happening?
... alternatively, why can't we just use the munged name?
... should we cover this scenario, too?
... we shouldn't depend on the change to infoset.

Ivan: do they want the rdfa spec written in terms of DOM?

Manu: specifically yes, as function of DOM level 2, and as infoset parser.

Ivan: don't they have to expose in terms of DOM2 anyways?

Manu: absolutely right, but the Infoset problem has nothing to do with DOM2 and what you can do in a browser.

Ivan: why do *we* have to specify that?

Manu:because it's not quite clear what you do in the case of an HTML document processed through an Infoset pipeline and resulting in a transformation from "xmlns:foo=http://example.org/foo#" in the source document to an Infoset triple in the Infoset model (namespace, localname, value) -> (null, "xmlnsU00003Cfoo", "http://example.org/foo#") -> all of our rules say something about "xmlns:" and nothing about "xmlnsU00003A" - so we need to clarify what we mean in this case, and point it out as a potential issue when creating an RDFa processor that utilizes an Infoset-based parser that does this to namespaces.

<msporny> I really, really have to go be on the HTML WG call now...

<ivan> ben, it is probably a good idea to write something about the usage of RDFa in (SKOS) vocabulary publication like the library of congress. I can add that later if you add the headline for it...