See also: IRC log
Stuart: Raman, you may particularly want to look at the CURIE discussion
<DanC> by popular demand, I'm stayin on the HTML call for ~15min
Raman: I looked
... I can live with them
Stuart: the f2f minutes remain open waiting for Dave to complete a fix
No regrets given; Dave proposed to scribe.
Stuart: The logistics page is up,
it needs work but does have the hotel in place.
... I have a block of rooms reserved at the Rodney for Sun, Mon, Tue. 89GBP/night, breakfast included
... Make sure you call to make your booking so that you get one of the rooms in the block
... If you extend your stay, you should get the same rate, but check the web as well because you might get cheaper rates for less recently refurbished rooms.
... If you book outside the block, that won't cause any headache for me or HP.
Stuart: Norm, you took an action.
Norm: Yes, I did, but then I thought better of it.
Raman: Is there a coordination effort? Absolutely. But it's not with respect to RDFa; RDFa is just in the noise compared to the schism.
Norm: I took my action to be with respect to RDFa
Raman: Right. But the larger issue definitely exists.
TimBL: Are they proposing
something that works with GRDDL, or are they just adding stuff
... To get this working, you have to have the readers and the writers doing the same thing.
... I think you should start asking people to put a profile in the documents.
... What they're trying to do is say that all RDF aware XHTML/HTML readers should understand these attributes.
... But in that context, the reference to GRDDL is just distracting. So which part are they supposed to use?
... To date, I think this has been a bit muddled, which doesn't work.
Stuart: Can you formulate that as a question or comment?
TimBL: I sent it as a personal comment.
Stuart: I think the deadline has been extended to Friday.
TimBL: I'd be happy if the TAG would endorse that concern.
Stuart: I've also heard you mention some concern about DTDs.
TimBL: I don't think new technologies should be based on DTDs. The validators are driven by DTDs, but that's a problem.
DanC: RDFa uses DTDs to specify the syntax of the language.
<Zakim> DanC, you wanted to look into the charter for RDFa w.r.t. DTDs
TimBL: So it's a DTD modularization approach
<DanC> "The first option is to use XHTML Modularization 1.1 to specify an RDF Semantics module that can be combined with existing W3C XHTML 1.1 modules. " -- http://www.w3.org/2006/07/swdwg-charter
DanC checks charter: yes.
TimBL: If you are an RDF-aware
HTML parser, then you don't need the DTD, you just need to know
... And when it gets to CR, you should know the spec.
... For XHTML, you see its MIME type, or you see the XHTML namespace in the XML, so you go to the namespace document and you find a pointer to the GRDDL and a note about the RDFa spec.
DanC: That's not the outcome the
WG decided on.
... They didn't put the GRDDL pointer in the critical path.
TimBL: Another reasonable way is to just say that you should understand the spec. Period.
<DanC> the RDFa follow-your-nose issue is http://www.w3.org/2006/07/SWD/track/issues/28
TimBL: I'm prepared to accept that, but I'm not prepared to accept a DTD in the critical path.
<Zakim> noah, you wanted to ask whether going to the namespace URI is enough
Noah: I think the situation is
that HTML has always had open content. It's always been OK for
me to put extra tags in there. In that respect, RDFa was always
sort of OK.
... On the other hand, as far as I know, if I had that old content, it'd point to a DTD that owuldn't help with follow-your-nose.
(Scribe missed a bit)
TimBL: No one's talking about
using an extension namespace.
... We're just adding attributes to the original XHTML namespace.
Noah: But I thought you said there was a namespace to dereference?
TimBL: The original XHTML namespace document
Noah: And the MIME type is what got me there, right?
TimBL: DTDs have never figured in the follow-your nose story.
Noah: DTDs tell you about the
vocabulary, the media type says roughly, read the XML
... That's not forbidden is it?
TimBL: In XML, DTDs aren't required, but I think the consortium should move on from DTDs.
Noah: If I put non-namespaced XML out there with a DTD, I think I can undersatnd things from the DTD.
TimBL: I don't really want to spend any time trying to build self-describing web using DTDs.
Noah: Fair enough.
Stuart: I'm trying to find out if
the TAG has any consensus comments it wants to make.
... I guess if it is going to have any, we need a draft of comments which I have none.
DanC: I sent a comment that said
please change your test suite to reflect the SHOULD in your
... TimBL, I hear you saying that it should be in the XHTML namespace document.
DanC: You can just do that as webmaster, I think.
TimBL: Yeah, I need to find out what the GRDDL spec says about how to do it.
DanC: There's a redirect in there, but I'm not sure how that works.
<DanC> ACTION: Tim consult with Dan and Ralph about the gap between the XHTML namespace and the GRDDL transformation for RDFa [recorded in http://www.w3.org/2001/tag/2008/04/03-minutes.html#action01]
<DanC> everything timbl has sent to the relevant list: http://www.w3.org/Search/Mail/Public/advanced_search?keywords=&hdr-1-name=subject&hdr-1-query=&hdr-2-name=from&hdr-2-query=berners&hdr-3-name=message-id&hdr-3-query=&period_month=&period_year=&index-grp=Public__FULL&index-type=t&type-index=public-rdf-in-xhtml-tf&resultsperpage=20&sortby=date
<DanC> tim's comment on DTDs is in http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Mar/0297.html
DanC: I can't endorse your first comment under DTDs, because of the charter, though I do agree with it.
<noah> I strongly concur with Tim's 4.3 point. RDFa fundamentally contributes to what the meaning of a document >is<; the fact that software may wish to extract such triples is secondary.
DanC: Putting the GRDDL pointer in XHTML is problematic.
<DanC> ah... good... the GRDDL spec doesn't say *never* look it up: "Some namespace documents, such as the XHTML namespace document http://www.w3.org/1999/xhtml have very many references to them. If GRDDL-aware agents were to retrieve these documents every time they processed a document referring to them, the origin servers of those documents could become overloaded. GRDDL-aware agents therefore should not retrieve such documents on every reference and should retain
<DanC> some cache or local memory of the transformations those documents indicate should be applied. To avoid misrepresentation of published information, GRDDL-aware agents should ensure that this local memory is up to date and should support user options to configure or disable the cache. See also section section 3.1. Using a URI to Access a Resource of [WEBARCH]." -- http://www.w3.org/TR/grddl/
Some discussion of the tension between self-describing and not beating the W3C web server to death extracting DTDs.
Stuart asks again for clarity on what comment we might like to make to the RDFa WG
Some discussion of whether or not the WG has produced a GRDDL transform that implements RDFa
<DanC> Progress on the RDFa GRDDL transform Fabien Gandon (Friday, 28 March) http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Mar/0355.html
<DanC> "So I guess this version of the GRDDL transform for RDFa is up to date with the current tests and specs as far as I know." -- http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Mar/0366.html
<DanC> gold star to Fabien
Stuart: It would take some
wordsmithing to change TimBL's message into something that
would get universal support.
... They've extended their comment period for this document through Friday.
... Ok, at this point, I think the TAG has no comment to make on RDFa, so I'm going to move on.
... I think we might want to say something about CURIEs in RDFa later.
... I find it odd that there's a normative definition of CURIEs in RDFa when CURIEs are defined normatively in a separate spec.
DanC: They wanted to talk about it and we said not this week
TimBL: Are we doing to invite them in the future?
Stuart: Yes, that's being negotiated.
DanC: WRT action-7, Olivier has a
neat diagram and TimBLs seen it, and we're meeting again next
... The diagram is almost public. Good news.
<DanC> (ah! olivier did indeed make the diagram world-access http://www.w3.org/2008/03/validators-chart )
Stuart: I'll leave that as
... Ok, a bigger issue is ARIA host-language embedding
<noah> Michael Cooper's summary is excellent, IMO
Stuart: There's a summary from Michael Cooper from today.
<DanC> (I cited Cooper's summary in the HTML WG telcon that I was just on)
Stuart: As a device for motivating discussion, I have two separate proposals that I think we could make.
<Stuart> Proposal #P1:
<Stuart> The no-namespace ARIA embedding approach is a workable pragmatic solution to a problem induced by the lack of support for namespaces in HTMLs (v1.0-5.0) and by the mixed, [encrusted,] behaviours of user-agents and associated libraries when presented with attribute names and values that contain colons. It is regrettable that this situation exists. In the short-term the TAG recognise the aria- 'prefixing' approach can and will meet the needs for embedding ARIA in a limited number of host languages. The TAG believe that the right medium term answer is that a uniform HTML behaviour is specified for the handling of attribute names and values that contain colons as means to co-exists in an XML namespaced world. In the long term the TAG is of the opinion that XML namespaces is the correct architectural approach for distributed extensibility of web languages.
Stuart: Straw poll? +1 for support, -1 for not, +0 to abstain?
<DanC> +0; i.e. abstain
<noah> I think this is in the ballpark, but it sort of skirts a key question, which is >why< we think it's worth the trouble to push for a more generalized solution in the medium term.
<DanC> (my tiny brain needs to stare at test materials)
<noah> We may believe that, but we haven't justified it in the above.
<dorchard> +1 to Noah
<noah> For reason above.
Norm: I hate to give the hyphens a toe-hold
<Stuart> Proposal #P2
<Stuart> We (the TAG) believe that the only approach consistent with web
<Stuart> architecture for embedding ARIA in host languages is the namespace based
<Stuart> approach. We will support ARIA in demanding namespace support in HTML5;
<Stuart> We will lobby browser/toolkit vendors to fix the namespace and
<Stuart> colon-name/-colon-value attribute support;... and we will wait loudly
<Stuart> until Hell freezes over! [was going to say 'quietly' but then what really
<Stuart> would be the point?]
Raman: I'd like to reiterate what Norm said, the hyphens are a new namespace mechanism whether you call it that or not.
Norm: But I note that the problem is one of credibility. If we say that and get ignored…we don't have any.
<DanC> (Al gilman forwarded test materials by hsivonen http://lists.w3.org/Archives/Public/www-tag/2008Mar/0069.html )
Raman: I think the credibility question goes both ways
<Zakim> noah, you wanted to say we need to work through the issues in Michael Cooper's note
Noah: I think we've signaled
informally before that we believe this is where we should
... Michael Cooper has provided a carefully crafted reply; if we're going to go in the direction of P2, we need to carefully consider and respond to Michael.
... Given a choice, with no further work, I'm closer to P1 than P2.
<Zakim> DanC, you wanted to say that I'm more or less at peace with the way ARIA is going: they did the URI-based design to the Nth degree; the experiment succeeded, and now they're
DanC: I like the pattern that
says you make up a full URI and play in your own
... Then when you are sure what you have is globally useful, you negotiation in some open process for short strings.
<DanC> "if it picks up steam, introduce a synonym that is a short string thru a fair/open process."
DanC: I'm not going to complain if the short string has a dash in it.
Stuart: I think they've tried all the ways around the problem. The solution they've got is pragmatic, forced upon them by the state of the world, and with some reluctance, I don't think there's a better answer.
Raman: But now there's an answer
to the earlier question. Working groups are supposed to get
intergrated into HTML by negotiation on an element-by-element,
... If that's where we are, that's what we should say.
Stuart: Once you start giving a toe hold, then the floodgates open.
TimBL: We have to be careful. I
think we should explore all of these angles. If you've got a
good relationship with the HTML WG, then you can negotiate it.
Maybe that's the cost effective answer.
... For other things, that's not going to work.
... I'm becoming more sympathetic to the first statement.
... But it shouldn't be taken as a precedent.
... The idea of using SVG without XML is horrifying.
... If I was writing a parser, I'd have a single parser that did error correction, displaying error messages, and only doing "view source" on the error-corrected tree.
... I suggest we tackle it from the ohter side as well.
... We (the TAG) should formally say there's a default namespace that comes from the MIME-type.
<DanC> (I'm party to the negotiation around ARIA in HTML 5; records are in/near http://www.w3.org/html/wg/tracker/issues/14 ; the issue is as yet still open; the agreements aren't done.)
TimBL: You could also add default namespace bindings for other namespaces.
<DanC> (I just chaired a discussion of it ~45min ago)
TimBL: It can be automated and it handles the legacy cases too.
Dave: I quite support what TimBL
was saying. I haven't been party to the HTML5/ARIA
... But could we use it as another use case for namesapces in HTML. Right now the HTML WG has a document about how to do vector graphics, distinct form SVG. I find that disturbing.
... Maybe one of the things we could do is say that this is another language mixing requirement.
... Eventually, that will encourage peopel to believe they they need/want namespaces for a general purpose solution.
... Right now the debate seems to be mostly around the single instances of vector graphics and math.
<Zakim> DanC, you wanted to say I think ARIA makes a poor use case for namespaces in HTML; the value of ARIA to the global community is sufficiently high that doing the desing,
DanC: I think ARIA is important
enough to the world that it makes sense to standardize it
... I think something like FaceBookML may be a better test case.
Raman: If you observe the pattern
that we went through for arai-role, and you see where SVG and
MathML are going. The world where HTML5 is is extremely far
away from where TimBL would like it to be.
... The HTML5 WG has put its foot down and said "no" to namespaces.
... Maybe that's the right thing for some cases, but that seems to be the *only* extension mechanism available.
... Solutions that work there, will be put in other places. The pain for doing it for a two attribute language may be small comapred to the benefit.
Raman: But for something larger,
it's going to be hard. For example, the HTML5 WG is proposing
that the MathML folks should need fewer elements.
... Saying we have one big, central spec with a single editor may work, but I don't think it will.
... It's naive for us to say that namespaces and XML will come into HTML in the future when the spec is being written to prevent that.
Stuart: Do you think there's consensus for that position in the HTML5 WG?
Some discussion of what consensus means in the HTML5 WG.
<Zakim> DanC, you wanted to think out loud about taking my position about ARIA and applying them to SVG and MathML
DanC: If you take my position on
ARIA and apply it to SVG and MathML, it breaks.
... it's sort of ok if the ARIA design gets re-done for HTML.
... but not for SVG or MathML. I didn't sign up to chair that.
Raman: The MathML guys are struggling for adoption, so they're pretty willing to do what it takes.
DanC: What I think is sort of positive is that they're telling each other their stories.
Stuart: At some point, we ahve to work out what our group position is wrt ARIA.
TimBL: I think we should say two things: something that says "go ahead and do this" for ARIA and another document that says doing this for SVG would really be a big mistake.
<DanC> (there's a non-trivial constiuency that believe re-designing SVG is cost-effective, meanwhile.)
TimBL: It would be unbelievably
costly to reopen SVG and it's absurdly presumptive of the HTML
WG to believe that they should be in total control of
... The consortium has sunk a lot of effort into this modular architecture so that the web can grow in a decentralized way.
... I'd even be willing to say this forcefully at an AC meeting.
<raman> quotes around attributes: parse <a href=foo/>foo is a mess
<Zakim> dorchard, you wanted to ask where the assertion about HTML5 WG saying no to namespaces has happened. I think it's still in the air
TimBL: I'd be prepared to compromise some of the XML rules in favor of replacing XML with HTML with no namespaces and a horrible parser.
Dave: I think it needs to be
stated on the record that Raman said that the HTML WG has said
"no" to namespaces. I don't think that point has been decided
... I find it ironic though that instead of redesigning SVG and MathML to make them fit in HTML, we'd redesign XML!
<DanC> (again, design cost is not the dominant one; the dominant cost is more connected to authoring practices and publishing workflows)
Dave: That would make all the XML languages be redesigned even though many of them will never be embedded in HTML.
<Zakim> noah, you wanted to say I think we need to cast the SVG story as an example of a general case
Noah: I wanted to pick up on what
TimBL said. Basically, I'm very sympathetic to that direction.
Take option 1 on ARIA but send a strong message on SVG and
other, larger languages.
... What I'm missing is that SVG is an example of a general case. Here's how you draw the line in the future.
... We need to find a way to articulate where that line is.
TimBL: If it's just a bunch of attributes and an element or two, something you can get the HTML WG and the TAG to review, I think that would be ok.
Noah: I'm surprised that remixing
wasn't part of that. For example, SVG might have uses far away
from HTML, so that makes the cost go up.
... That would be desirable for ARIA but we're sort of letting that one go.
... It's not just a question of size, it's about the containers that you might want to put them in.
Raman: I don't think its the
container. There are two extremes: one is a module that is just
attributes. XML events, for example. The reason that attributes
are easy is because they don't contain markup.
... At the other extreme, you have a language that's purely elements. Today, I might be able to say where in HTML you could graft in those elements.
... The real pain point is that the embedding doesn't stop at one level. Attribute are constrained by the technologhy.
... HTML wants to contain SVG which contains MathML which contains HTML.
... The leakiness of this, when you cut and paste, for example, is the problem.
<Stuart> FWIW: I asked Michael about what ARIA-WG would recommend for embedding ARIA in XHTML response at: http://lists.w3.org/Archives/Public/www-tag/2008Apr/0011.html
Raman: In Atom, for example, the HTML gets put in as a blob. As long as the HTML view of the world is that I will not only error correct but I will also consume everything the problem is insurmountable.
<DanC> (is Atom really losing the XML-wf battle?)
<Zakim> timbl, you wanted to suggest that DaveO doesn't understand the total cost and impliction s on XML of this path .. it will start with ebedding HTML inside his XML PO which will
TimBL: I support what Raman said. Changing XML would affect your purchase orders, but putting HTML in your POs will then force you to change them all anyway.
<DanC> (well, no, I think there's a world of purchase orders and such that have no interaction with HTML. It's not considered "on the Web" by many, and in fact, its community is pretty disconnected from the HTML+CSS+JS community)
TimBL: An HTML parser has to know which elements have to be empty. I think if XML isn't fixed and we don't go to a lot of effort to make it and namespaces easier to use, you'll wind up with tag soup *everywhere*
<DanC> (phpht. my phone battery died)
<noah> I'm very nervous about "fixing" XML, not because there isn't merit in principle, but because we've seen that even isolated changes like XML 1.1 are extremely hard to deploy in practice.
<noah> The XML community values stability, IMO, almost above all else.
Dave: I think it's bigger than quoted attribute values, like Norm said.
<raman> <a href=foo/>foo is a mess here
Dave: I'm in favor of changes, I
just want to know what the scope is.
... I think the community is ready, maybe better integration with HTML is the killer use case.
<noah> As Dave is saying, I'm not against changing XML, but iff users will see compelling cost benefit. So far, we've shown relatively poor ability to make the call of what users will actually deploy wrt/ XML changes.
Stuart: I wanted to try to place
... Noah, would you be able to do some shaping on the proposal I labeled as P1?
<jar> #P3: ??? Web architecture (which is the TAG's realm) implies namespaces. We recognize that they are incompatible with HTML5. Ergo HTML5 lies outside our charter. Wish them well, ask them to be as namespacey (and web-archicture-following) as they can, it's up to them how to do it. ?????
Stuart: We need to start giving
some messages back, and I wonder if you'd work on it.
... And I'm going to press TimBL to draft the other message.
Raman: I suggest that if we're telling the ARIA people that what they're doing is OK, we just send a one-liner to say that. Then write a longer, single document that outlines both positions.
Noah: I'd be glad to take a little time right after this call to wordsmith what Stuart wrote just a little bit. Simply make the point that in this particular case, notwithstanding our reservations, we think it's ok.
... I also wanted to place a second action on TimBL to draft the other piece.
<scribe> ACTION: Noah to wordsmith Stuart's P1 proposal [recorded in http://www.w3.org/2001/tag/2008/04/03-minutes.html#action02]
Stuart: I don't want us to lose the stronger piece
<scribe> ACTION: Tim to draft to a stronger piece outlining when the ARIA approache would not be practical [recorded in http://www.w3.org/2001/tag/2008/04/03-minutes.html#action03]
<timbl> A piece about the need for HTML modularity