See also: IRC log
ACTION: [DONE] Ben draft WWW2006 proposal for talk describing RDF/A language [recorded in http://www.w3.org/2006/03/13-htmltf-minutes.html#action13]
-> WWW2006 Talk Proposal: RDF/A - Interoperable Metadata for XHTML [Ben 2006-03-19]
ACTION: Ben to develop a plan for a marketing/news web site about RDF/A and send it to the list [recorded in http://www.w3.org/2006/03/13-htmltf-minutes.html#action16] [CONTINUES]
ACTION: Ben update his bookmarklet for XHTML mode [recorded in http://www.w3.org/2006/03/13-htmltf-minutes.html#action12] [CONTINUES]
<Ralph> [Ben finally got me to look at his RDF/A bookmarklet last week and I was very impressed]
Steven: IE looks at the last characters after the last '.' in the URL, plus the Mime type, so you can fool it with '?.html'
Ben: I'll take a look at issues in my RDF/A bookmarklet with local file extensions. My bookmarklet does point out what's unique in combining metadata with html
-> talk and RDF/A bookmarklet [Ben 2006-03-08]
ACTION: [DONE] Mark draft WWW2006 proposal for RDF/A demos talk [recorded in http://www.w3.org/2006/03/13-htmltf-minutes.html#action14]
-> WWW2006 Session Proposal: RDF/A in Action: Enabling Semantic Web Clients [Mark 2006-03-20]
ACTION: Mark, Steven, and Ralph respond to Ben's off-list draft of response to Bjoern [recorded in http://www.w3.org/2006/03/13-htmltf-minutes.html#action05] [CONTINUES]
ACTION: Ben start separate mail threads on remaining discussion topics [recorded in http://www.w3.org/2005/12/06-swbp-minutes#action04] [CONTINUES]
ACTION: Ben talk off-line with Jeremy about a realistic implementation schedule [recorded in http://www.w3.org/2006/02/21-htmltf-minutes.html#action01] [CONTINUES]
ACTION: Ben to draft full response to Bjoern's 2004 email [recorded in http://www.w3.org/2006/01/24-swbp-minutes.html#action03] [CONTINUES]
ACTION: [PENDING] Jeremy followup on HEAD about= edge case [recorded in http://www.w3.org/2005/12/06-swbp-minutes#action03]
ACTION: [PENDING] Jeremy followup with Mark on the question of multiple triples from nested meta and add to issues list [recorded in http://www.w3.org/2005/12/06-swbp-minutes#action01]
ACTION: [PENDING] Jeremy look into the XHTML namespace issue and write thoughts into email [recorded in http://www.w3.org/2006/03/06-htmltf-minutes.html#action02]... next
ACTION: [PENDING] Jeremy propose wording on reification [recorded in http://www.w3.org/2005/12/06-swbp-minutes#action02]
ACTION: Ben review Jeremy's actions [recorded in http://www.w3.org/2006/03/20-htmltf-minutes.html#action14]
ACTION: Mark work on a first draft of an RDF/A XHTML 1.1 module [recorded in http://www.w3.org/2006/03/06-htmltf-minutes.html#action01] [CONTINUES]
Mark: we're planning a release soon of software that makes use of this, so hope to get it done by the end of the week
ACTION: once Steven sends editors' draft of XHTML2, all TF members take a look and comment on showstopper issues only [recorded in http://www.w3.org/2006/02/06-htmltf-minutes.html#action01] [CONTINUES]
ACTION: [WITHDRAWN] Steven draft a WWW2006 Developer's Track proposal [recorded in http://www.w3.org/2006/02/21-htmltf-minutes.html#action16]
Ben: any preliminary thoughts on how much of RDF/A can fit in XHTML 1.1?
Mark: most of it, I think. CURIEs will be tricky. We're only talking about schemas to validate, which is easy. The next step, processing, is where the work lies. Ben's bookmarklet shows what's possible, though CURIEs will be trickier to process; this will be hard in XSLT1 but it's doable in javascript. Should we constrain ourselves to what browsers can easily implement? QNAMEs are hard to deal with in XSLT1. A long time ago I felt QNAMEs could be split apart in XLST1, possibly requiring a function definition but validation should not be hard. We do need to decide whether we want to produce a subset of what can be implemented. Looking at Ben's bookmarklet and our sidebar, go with what we think we can implement
Ralph: is it a problem that we want to allow href's everywhere?
Steven: the problem is not with XHTML 1.1 but with modularization. There are already modules with href; if we allow html:href everywhere then some modules end up with two hrefs, which is not allowed so we have to redo some of the existing modules to remove href from them
Mark: if we allow href everywhere in current browsers it won't neessarily result in a navigable link. Should we be encouraging this if we know it's not implementable?
Ben: suppose we don't add href everywhere but just permit it on META and LINK in the body? XHTML 2 would permit href everywhere
Mark: yes, that's what I've been thinking; allow META and LINK everywhere, add 'property', add 'about', add 'datatype'. This gives a lot of RDF/A. It allows complex things like RSS feeds but requires META everywhere or use 'property' but with href only where it is currently allowed
Steven: could permit href in more places, just wouldn't be clickable
Ben: we don't need for the RDF/A module to fix all XHTML 1.1 issues; places that are not clickable just couldn't be used
Mark: permitting META and LINK everywhere is not an enormous leap, since 'rel' and 'rev' are permitted
Ben: seems like a good place to start
Steven: I need to think about it a bit longer. I'd always imagined that RDF/A was predicated on href being available everywhere
Ben: if the base XHTML doesn't allow href everywhere we just go with where href is allowed
Steven: I'd want to try it out and see how it looks
Mark: I want to be clear on what we're trying to do. Steven thinks we should go all the way. To have href everywhere requires changing a lot of modules. There's no point in doing that if people complain it can't be implemented in lots of browsers so we need to decide what direction we're going. As far as XHTML1 is concerned it's probably best if we don't do more than what browsers can support. The idea of XHTML 1.2 would require rewrites of modules
Steven: I see the advantage of href everywhere. In the short term they're not clickable links but the browsers will accept (and ignore) the content and the triples will be there so we just have to wait for browsers to catch up and implement href
Mark: looking at Ben's work, he could have made the additional hrefs in XHTML1.1 clickable
Ralph: I'd suggest that we anticipate a direction. It would be nice if HTML WG suggests whether an XHTML 1.2 might happen and whether href everywhere is high probability for that. So if RDF/A 1.1 module anticipates that href will be everywhere, we can give that advice to authors. If they want the link to _not_ be clickable in the future they should use META or LINK now. If they're happy that the link might become clickable someday, they can use 'href'
Steven: we can add about and property everywhere, it's just href that's a problem due to existing 1.1 modules
Mark: to help the uptake of RDF/A, the question is whether we should go for the whole thing from the beginning. If people use href when it's not clickable will it cause problems later?
Steven: doesn't feel like it would be a problem in the short term. XHTML 1.0 modularization is a W3C Rec, XHTML 1.1 modularization is at Proposed Rec
Ralph: I was hoping for a document that would show us what things would require changes to either XHTML 1.1 modularization or to existing modules
Mark: I didn't want to have to solve hard problems that we decide later don't need to be solved
Ralph: deciding whether to go with href everywhere requires a statement from the HTML WG on whether it is willing to undertake the necessary changes to other modules
Steven: but that is work the HTML WG is likely to do anyway
Ben: let's start with a simple version; href everywhere requires more work from the HTML WG. Let's start simple assuming href everywhere would not be wasted work
Mark: right, not wasted work -- just need to decide whether to release it
Ben: we submitted two proposals and had to tell the organizers that these were not meant to be duplicates.
-> WWW2006 Talk Proposal: RDF/A - Interoperable Metadata for XHTML [Ben 2006-03-19]
-> WWW2006 Session Proposal: RDF/A in Action: Enabling Semantic Web Clients [Mark 2006-03-20]
Steven: I have been asked to talk in the W3C track. I haven't yet coordinated with the track organizer what exactly I'll be talking about. I'm holding back to see which of our Dev Track proposals get accepted
Ben: this came up in Creative Commons discussions. The idea is to allow multiple values in 'rel' and 'rev'
Mark: I think that's a great idea and thought we'd discussed it
Steven: we decided it for 'role' in the HTML WG
Mark: looking at 'class', 'role', 'profile', you start to think "why not?"; hard to stop
Ralph: I'd want to think about what the implications are for triples
Steven: for 'role' it's clear, for 'rev' there are fewer use cases
Ben: I gave one example in this telecon agenda .I'd like us to think more about this for next time; since triple generation is driven by predicates, it seems straight-forward. Microformats have a feature like this already
Ralph: so the suggestion is simply to add this feature because microformats find it as useful?
Ben: yeah
Ralph: current SWBPD charter expires end of April. The current intention within the SemWeb Activity charter drafting effort is to proceed with RDF-in-XHTML task force as part of a new WG, with REC-track responsibility owned by HTML WG with support from SemWeb Activity and deployment responsibility -- e.g. Primer -- the primary responsibility of the SemWeb WG
Ben: I'll start planning WD #2 based on comments received; e.g. people have suggested acknowledging previous efforts
Mark: I'd like to see what form this would take [before concurring]; e.g. Mikah Dubinko wrote a short article suggesting the use of attributes very similar to what we've chosen but I don't think there's really much prior work that got used directly in RDF/A though a lot of this was "in the air"
Next meeting: 27 March, regrets from Ben