W3C

TAG Weekly

12 Jun 2008

Agenda

See also: IRC log

Attendees

Present
Ashok Malhotra, Noah Mendelsohn, David Orchard, T V Raman, Jonathan Rees, Henry S. Thompson, Stuart Williams
Regrets
Tim Berners-Lee, Norm Walsh
Chair
Stuart Williams
Scribe
Henry S. Thompson

Contents


Admin

SW: Minutes from last week: http://www.w3.org/2001/tag/2008/06/05-minutes
... Approved as circulated
... Agenda for today: http://www.w3.org/2001/tag/2008/06/12-agenda.html
... Approved as circulated
... Next meeting 19 June, DanC to scribe
... Regrets from NM for 19 June, likely regrets from DO

Minutes from F2F of 2008-05-19 et seq.

SW: I've added some links, propose to approve with a typo correction as noted by JR

RESOLUTION: F2F Minutes (http://www.w3.org/2001/tag/2008/05/19-minutes, 20-minutes, 21-minutes) approved

News, new topics

SW: A new standing agenda topic to allow for late-breaking news

namespaceDocument-8 status

HST: Going to publish it Real Soon Now

passwordsInTheClear-52 status

DO: Haven't yet solicited external reviewers' comments on the most recent draft: http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20080602

SW: Some positive feedback from MEZ

<DanC> "Every scenario that involves possibly transmitting passwords in the clear can be redesigned for the desired functionality without a cleartext password transmission."

DC: I explored the W3C's situation wrt passwords in the clear
... Spellchecker tool, for example, uses a form to collect name/pwd for access to a member-only document
... We have never found a way to provide this functionality w/o pwd in the clear

DO: Rather than hold up/change the doc't, we should query the Sec'ty Context WG folks on how to get this functionality w/o pwd in the clear

SW: DanC, can you bring that up on our list, as a direct question to Security Context WG?

DC: Will do

<DanC> yes, jar, I suppose capabilities are about the only thing I've seen that could work

<jar> Since Dan brings this up, the reference for capabilities would be erights.org.

<jar> well... yes, I brought up capabilities. Let me turn that into a hyperlink: http://erights.org/

<DanC> nifty stuff, in theory, though it involves a whole new operating system etc.

<jar> right.

<jar> well, it can all be done in user mode of course, but it is a sort of mini OS kernel to manage the object-capabilities.

tagSoupIntegration-54

TVR: Deep questions behind specific integration issues, e.g. SVG, : vs. -, MathML
... HTML4 had problems, we said we would move to XML, which gave us XHTML, HTML5 is a temporary blip but XML is the long-term goal

TVR: that's one extreme

TVR: The other extreme is that XML has no future on the Web, all we need is HTML, HTML5 is the future
... Maybe there's a middle way, as suggested by Tim's statements 18 months ago and at the Beijing AC meeting

TVR: The hard question, as at the end of the last weeks call, is how can XML change a bit, HTML change a bit, to foster a convergance

scribe: My concern is that the parts of the two communities willing to consider change is so small that it doesn't matter whether we can find a technical solution or not
... So maybe we have to just accept that we are going to have two parallel tracks indefinitely

<noah> I'm afraid I agree with Raman, at least on the XML side. I think that in practice the XML community values its base of installed code to such a significant degree that changes will be very hard to deploy in practice.

<Stuart> noah... is that not true of both worlds: install base restricts flexibility, both way round.

<noah> Probably. I just don't feel that I am as well informed regarding the HTML community.

AM: But what's your opinion?

TVR: I'm reserving my position to avoid prejudicing the discussion

TVR: Where I am isn't the question, the question is whether there is any possiblity of a critical mass forming to support convergence

SW: So you want us to say whether we think convergence is possible

TVR: No, that's not the question, we have technical solutions, the question is about willingness to adopt those solutions
... Attribute quotation, for instance, is not the issue that matters. What matters is things like document.write
... The HTML world is not waiting for unquoted attributes and then they'll say Yes, we're ready to converge

TVR: The major issue is social, not technical

HT: A lot of the issues are social
... I think it's none-the-less worth getting clear on what the substantive technical issues are
... because they are the hooks the social dynamic is going to swing from
... mime-type-based ns-declarations seems viable, and would probably be accepted by the core XML community because it wouldn't affect them
... What else?

TVR: There's lots of 'real' namespace use in business/commerce

TVR: Well-formedness -- a real problem from the HTML side

<raman> xml community: clarity around namespaces, especially null namespace vs no-namespace

TVR: ns decls from mime type, yes, although that doesn't get us all the way to distributed extensiblility, where someone designs there own mini-language

HT: That needs a change on the HTML side

TVR: Right

NM: A lot of sympathy with TVR's concerns, we've gone too far in the past ignoring implementation/deployment difficulties
... But not sure separating issues in two piles is helpful
... For many of our users, what you call it matters: XML means very high expectations of interoperability
... Unlike, for example, C
... So it's really hard to get change through on the XML side, and that's right at the boundary between technical and social
... Asking "Will the community accept media-type-ns-defaulting, or unquoted attrs?" I don't know -- maybe more likely for the first, but possibly hard for both
... People worry about any change destabilising the interop guarantee

DO: Simple use case I hit -- The BEA Aqualogic Portal project, has remote portlets, you can drag and drop XML on them
... The engineers said: We can't mix HTML and XML easily, what do we do? The XML guy won, and enforced strict well-formedness
... But the product managers were upset, because the said customers' expectations would not be met
... Can we rev XML? Suppose we relaxed a bunch of constraints, maybe that would make a bunch of the HTML folks happy.
... The core issue for some of the HTML WG is namespaces/distributed extensiblity -- they don't want it in any form
... Because the two worlds are so different, it's easy to reject any kind of convergence
... but if we relaxed some of the XML constraints, that might make a change

<Zakim> Stuart, you wanted to introduce a question arising from Steve Pemberton's message http://lists.w3.org/Archives/Public/www-tag/2008Jun/0037

<Stuart> With these things in mind, we feel the best course of action is to declare that all documents using the xhtml namespace http://www.w3.org/1999/xhtml are capable of being interpreted to produce RDF triples.

SW: This is an ambition for all documents -- doesn't that mean there's a need for liaison between the two developers of languages in the namespace, i.e. XHTML2 and HTML5

TVR: There is a lot of opposition to RDFa from people in the HTML WG, partly because of its use of namespaces, partly because of an antipathy to RDF itself

SW: HTML5 WG is positioning itself as the successor to both HTML4 and XHTML1

DC: The WGs were chartered to compete

TVR: From a TAG perspective, the question is, is the community which is commited to finding a convergent path large and significant enough to make a difference
... Bearing in mind the TimBL counts for a lot
... Alternatively, if we are resigned to the two tracks running in parallel, can we see any route towards peaceful co-existence
... Both these technologies have a place on the Web, and will survive, with or w/o the W3C

DO: Helping to reconcile the XML and HTML communities should get a lot of our attention

URNsAndRegistries-50

SW: HST, can you summarize activity on relevant email threads?

HST: No, sorry, have not had time to give the threads the attention they need

NM: There have been concerns expressed about how well the TAG coordinated in the lead-up to our note to the community
... I'm happy with what we did on the technical front, but our care in ensuring that people aren't blindsided could have been improved
... We should take note of the coordination concern

NM: and try to have a "no surprises" approach to communication

AM: What response is now appropriate?

HST notes that Stuart and Tim are working on an official response

SW: Should we encourage any kind of dialogue? I think we should

<noah> NM: I would like to do what we can moving forward to ensure that we can work cooperatively with the Oasis community to find whatever is the right answer in the long term.

SW: On the basis that we will try to understand their requirements, and to help them understand our concerns

<DanC> +1 invite XRI folk to a telecon

DO: The idea that XRI was surprised that the TAG should speak out against XRI is itself surprising

<noah> FWIW, I also think the XRI community could have done a much better job over the preceding months of taking our concerns seriously, and indeed operating from a perspective that the burden is on any community proposing a new scheme to justify the need, given the many downsides.

DO: HST and DO engaged with them over URNsAndRegistries-50 two years ago, and it was clear at that time that they were not going to be convinced of our position wrt the potential utility of http: to meet their needs
... So they can't have been under any illusions that we weren't happy

<raman> the technical community is always guilty of doing the type of marketing that Dave is describing, e.g. use SOAP, you can get through firewalls is one bogus argument I remember from the past;-)

DO: I doubt the utility of engaging in a huge amount of effort to end up where we started

<raman> I dont think what DO is saying here is material to making positive progress

DO: I don't think we have anything to apologise for
... I have finally heard an interesting use-case in the area of synonym identifiers, but it's still not clear that that is worth the cost of creating a whole parallel naming authority mechanism
... Going forward, the XRI TC are already looking towards the question of when they can go to ballot again
... Does that mean they've heard our message?

SW: XRI TC have been receiving comments that they should engage in more dialog with the TAG.

TVR: Allowing a confusion between the TAG speaking technically and the W3C speaking hurts both sides

<Zakim> DanC, you wanted to sympathize with the concern that we didn't close the loop with the XRI TC.

<DanC> 29 Feb msg http://lists.w3.org/Archives/Public/www-tag/2008Feb/0104.html

DC: We still owe the XRI TC a response to their email of 29 Feb

SW: You happy with the goals I suggested above for a call?

DC: Yes, and asking people to a telcon sounds good

HST: We have to be carefully not to suggest to them that there are things they can do to 'fix' XRIs

SW: If we don't talk to them, the likely outcome is that our concerns will be lost sight of, because we will appear to be uncooperative

<Zakim> noah, you wanted to talk about better coordination vs. we own the Web

NM: There is a real positive inclination on the part of the XRI TC to talk to us, and we should meet them on that basis

<DanC> (re "doing nothing is a good answer" ... well, I think doing something on top of http/dns is the sweet spot.)

NM: They need to change how they think about this, so that their job is to prove that there is enough value to overcome the very real costs

<raman> dropping off

<Zakim> jar, you wanted to float the idea of eventually putting application of http: to naming problems on rec track

JR: A durable solution needs more than a TAG finding - there needs to be a manual or something that helps groups like XRI when they have a need for a naming scheme

<DanC> not obvious? really? everybody and his brother makes namespaces out of http/dns. It might be worth writing up/down, but LOTS of people figure it out by themselves.

<noah> NM: Maybe time to tilt at the Scheme/Protocols finding again?

<DanC> e.g. flickr tags, wikipedia pages, and zillions of others

Summary of Action Items


Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/06/19 17:06:59 $