Attendance: Tim Berners-Lee, Dan Connolly, Roy Fielding, Noah Mendelsohn, David Orchard, Vincent Quint, T. V. Raman, Henry S. Thompson
Scribe duties:
Friday session runs 1330--1730
No telcon on 7 March.
14 March Telcon: Regrets from VQ, TBL. ER to chair in VQ absence. NM, DC are at risk. DO will scribe.
F2F in June confirmed for Western Massachussets.
Next F2f thereafter, late September/early October, Vancouver? Three days -- 3--5 October? To be confirmed at a later meeting.
December meeting -- AC is in Japan 29--30 November. XML 2006 is 5--7 December (?) in Boston. Maybe have 'winter' meeting at MIT around then, e.g. 6--8 December. Revisit in due course.
NM: Last telcon agreed I would talk to NW and agree, we did that, agreed minor changes (remove final BPN), NW has the text and is preparing to publish it as a finding.
VQ: I've read this and I think it's good.
NM: TBL, your name is on this, you still happy?
TBL: Yes.
VQ: Action will be finished when, after publication, an announcement goes to www-tag.
VQ: How can we increase the likelihood that WGs will discuss architectural issues with us at the right time and with real effect? One possiblility is to be sure that charters have TAG liaison written in to them. Another possibility is to institute a regular "Intro to WebArch and the TAG" session at the first f2f of every new WG.
HST: Real resource implications for either of these, particularly for the first option -- watch for new charters, bring them to telcons, draft wording, sending it back. . .
TVR: Risk we are seen as yet another irritating step in an already cumbersome process.
DC: Well, I already read charters, www-tag is a perfectly good place to comment on them, I hope we'll use that social process, we don't need more formal process. . .
DO: Is there an example where we later found a particular bug which one of these ideas would have fixed?
DC: Well, certainly anyone starting a WG at the W3C should have a basic understanding of WebArch. We take up issues when they're sent to us, we don't need new mechanisms.
NM: It was suggested that the XMLP workgroup might be responsible for producing RDF to describe some facilities such as message exchange patterns. There was pushback that the group didn't have the skills or time, and that its charter doesn't suggest the requirement to do so. If there's an expectation that a WG will in some way produce RDF, how is that established?
DC: Is the Process Document the 'bare minimum' or a 'best practice' statement?
TBL: Problem is that PD is not about substance, but about process -- if we put a WebArch requirement in the PD, that will just turn in to a bit of boilerplate.
NM: Forestalling the "it's not in our charter" objection to a particular WebArch-motivated task in a WG might be helpful. . .
DC: So, what are the next three WGs we're going to run in to?
DC: SWRules have started, with some WebArch intro, HealthCare/Life Sciences are OK too I think. . .
HST: What about XGs?
DC: No, explicitly exempted.
DC: TBL or SB read every charter at least once, that's sufficient mechanism for me. . .
DO: Our (TAG) charter says we're not supposed to do Process stuff. . .
VQ: My point in raising this was to focus on communication, not Process. . .
TVR: In principle a lot of this should be happening in the CGs, but the problem is that in many cases the chairs who constitute a CG aren't familiar enough with WebArch. . .
DC: Example?
TVR: I had to push long and hard in the Multimodal WG to get DOM Eventing taken seriously. . .
DC: Sounds like a success, not a failure?
TVR: Took too long, opportunity (which has resurfaced as the WebApp effort) was missed. . .
VQ: Doesn't sound that there's any general action or principle, but it sounds like continuing on a case-by-case basis is the best we can do.
DO: The WSAddr/EPR issue was no surprise to anyone, we knew it was coming up, don't know if the TAG is happy with the outcome. The TAG talked about it very late in the life-cycle, despite it being issue 1 on the WSAddr issue list.
DC: Part of problem is Team member on the WG feeling they can't interfere in a complex issue.
TVR: Is there a single Team position on any issue?
DC: Yes, like any other group rep on a WG, they speak for their organisation.
HST: In this particular case the Team, in the form of the Arch Domain, talked long and hard about this and sent the Team rep back to the WG with an agreed position.
TBL: The situation was complex in this case, because what all this was for was not clear to either the Team or the TAG, so it was hard to push back on clear and simple architectural grounds.
TVR: My experience in a number of WGs is that the Team position doesn't come across as more than the individual Team member's personal view. Perhaps we could use some of the TechPlenary time to publicly elaborate more worked-out Team positions.
DC: I was just saying Team member is no different from anyone else on a WG -- by definition they speak for their organisation, whether or not they have consulted widely.
NM: I certainly wasn't happy with the way the WSAddr thing worked out. We started with RefProp and RefParams, the one which was explicitly about identification (RefProp) attracted pushback from the TAG, the WG dropped that one. Apparent success, right? Wrong -- the functionality from the RefProp migrated into RefParam. This came up to the TAG only by accident, as it were, when Mark Baker raised an issue which was actually about something else.
DO: It wasn't a matter of covert intentional subversion, just a recognition that the core functionality of RefParams, namely echoing, included identity as well.
NM: To summarize my comments on the WSA issue. I don't think they way they and we coordinated was a good model for the future. When the distinction between reference parameters and reference properties was eliminated, we missed a chance for the TAG to be alerted that there were still plans in some cases to use refParms for identification. I think the practical implication was that the TAG eventually realized the true state of play later than was ideal. The good news is that we all eventually converged on a mutually acceptable answer, but I don't think the process that led us there was a model for future interactions.
TVR: Better coordination between WGs and the TAG is easy to ask for, but if the TAG was really successful, WG--WG coordination would happen on its own. That's why I thought the TP might offer a place for evangelisation.
VQ: Didn't we use to have a TAG slot at the TP?
DO: Yes, we did something two years ago?
VQ: So should we resurrect this?
TVR: Yes, and maybe base it on trying to find e.g. pairs of WGs whose interaction raises a TAG issue. For example, when WebArch issues arose for VoiceBrowser WG, it always came too late and felt like being told "You should do X" instead of knowing for themselves that they should ask "What about X?"
DC: What's the proposal?
HST: Comes down to making sure VQ asks for a slot at the next TP.
DC: What for?
HST: As TV said above.
DC: Where's the beef.
DO: Late-bound -- that is, at the time we look for two or more WGs in the right situation.
VQ: That's enough on this topic for now.
VQ: The main difference between this and xmlFunctions-34 seems to be that this topic, which emerged at our last f2f, isn't yet logged as an issue.
VQ: This topic emerged as we discussed what it means to add a new language to the Web, when existing processors/agents don't know anything about them. The bar to entry is lower when new technologies are self-describing, so support can be created (semi-)automatically.
VQ: Whereas xmlFunctions is about how we get at the 'native' semantics of a particular XML document.
VQ: DC, you said you can't tell them apart -- how so?
DC: Well, I hear what you're saying, but whenever I drill on one or the other I end up in the same place.
NM: Well, seems to me the one (xmlFunctions) is a subset of the other (self-describing). Self-describing covers the whole Web, not just XML. Also, the xmlFunctions story as it's emerging is about only one (important) aspect of XML document interpretation. Maybe for XML, functions are all that matter, but that's certainly not the same as for the whole web question.
HST: (new URI scheme or media type vs. new namespace)
TVR: Yes, but new XML language shouldn't require a new namespace in every case -- adding new element to an existing language shouldn't require a new namespace -- we have too many already.
TBL: Yes, these two are not the same, but we should still tell a single story about SDW, just that in some case we'll get to xmlFunctions as a part of the "follow-your-nose" flowchart.
TBL: Once we get to XML, we're at a bit of a deadend, except in two cases, compound documents, where we can talk about mixing namespaces, and RDF.
TBL: But I want to keep the SDW question at the top of our concern, to make sure there are no gaps. Imagine a media type which specifies a default namespace for a class of document with no in-document use of namespaces, that should be OK.
ER: Not if XML doesn't recognise it.
TBL: A cooperation would be needed, yes.
NM: Not disagreeing with TBL, but want to remind group that I think namespaces are a red herring, rather it's root element. Multiple document types may share a namespace, just knowing the namespace isn't enough.. Wrt TVR, he didn't use the word 'versioning', but that's at least a common source of the kind of example he was raising. At least, we need to keep relations clear between this topic and the versioning one.
TVR: You get a content-type header that tells you what to expect. Then you get a document, and its namespace tells you the vocabulary. Minor variations in the vocabulary, e.g. from versioning, should not trigger a new namespace.
TVR: Also, the information available via content-type is in some sense a piece of "computed" information that has been "computed" from the content stream. Therefore, it's important that that information not conflict with what follows later. It's always possible that you'll get more information as you process the content stream (http body) but the content-type is an important optimization bit that should be used intelligently.
NM: We could tell people "When you version your XML language, the versioning variation should be patent via our 'standard' xmlFunction story."
TBL: Was this a discussion, or a meta-discussion?
HST: I think we got to consensus around TBL's summary, namely, these issues are related, addressing SDW will involve addressing xmlF. It's important to keep SDW as the starting point/overall context, to ensure nothing falls through the cracks.
[See second session]