W3C | TAG | Previous: 28 June | Next: 19th July

Minutes of 12 July 2004 TAG teleconference

Nearby: Teleconference details - issues list (handling new issues) - www-tag archive

0. A new addition

Resolved The TAG extends its heartiest support and congratulations to Ian and Valerie on the arrival of their daughter.

1. Administrative

  1. Roll call. SW (chair), NW (scribe), CL, DC, RF, TBL, PC. Regrets: IJ :-)
  2. Resolved to accept the minutes of the 28 June teleconf?
  3. Accepted this agenda?
  4. Next meeting: 19 July. Norm Walsh to Chair. Likely regrets: TBL, PC. Regrets from IJ.
  5. Action SW 2004/06/28: Send an ack re DO/TB editing roles on www-tag. Done

1.0.1 AOB

  1. SW reported that he had asked PC who as agreed to prepare our monthly summaries for the AC.

1.1 Meeting schedule

Action TAG 2004/06/07: Send summer regrets to TAG list.

  1. Ottawa meeting update
    1. Action NW/PC 2004/06/14: Prepare ftf meeting agenda. See email from Paul

[Norm]

No updates for Ottawa local arrangements.
NW/PC will publish an agenda shortly after 21 July
Regrets from DO

1.3 TAG Charter

Pending further updates from Team/AB

[Norm]

No news

2. Technical

See also open actions by owner and open issues.

2.1 Action Item List

  1. Proposal on done/moot action items: see email from SW

[Norm]

CL reports completing his action

2.2 IRI draft status in IETF

  1. Action CL 2004/06/28: Tidy up draft and send to I18N WG, copying www-tag (as a response to Addison).

[Chris]

uri for my closed action
http://lists.w3.org/Archives/Member/w3c-i18n-ig/2004Jul/0006.html

2.3 httpRange-14 status

  1. Action TBL/RF 2004/05/13: Write up a summary position to close httpRange-14, text for document.

    Propose: Roy's action close by email. Will need to reschedule httpRange-14 when TBL available - single issue telcon? guest?

[Norm]

Action TBL/RF continued

2.4 XMLChunk-44

  1. Action NW 2004/05/12:

    "Write up a named equivalence function based on today's discussion (e.g., based on infoset, augmented with xml:lang/xml:base, not requiring prefixes, etc.)."

    See email from Norm

  2. Next steps...??

[Norm]

NW action complete
NW suggests we could add markup and turn it into a finding
Some discussion of what the appropriate next steps are. Some concern expressed that the world won't care.
[DanC]
asking I18N seems worthwhile
[Chris]
explicitly saying that lang would have been a good infoset property would be clearer. it should have been but isn't.
timbl++ on the 'it would have been nice if' finding. Valuable for next round of rechartering for example
[DanC]
yup. "if we're ever back in this design space, let's do it this way next time..."
[Chris]
i hea timbl proposing this and Chris and Paul seconding
[Norm]
Some discussion of possible next steps
[Chris]
don't hear any contrary opinions
[DanC]
I note this unspecified nature of infoset equality is relevant to a (last call?) comment I sent re XQuery
PROPOSED: nw write up xmlchunk proposal, adding a bit of history: how we got here, where we might go if we had it to do over again
[paulc]
+1
[DanC]
found my comments on xquery that are relevant to infoitem equality: XML query constructors: not well-defined http://lists.w3.org/Archives/Public/www-xml-query-comments/2001Apr/0014.html
[Norm]
TBL wants emphasis on where we might go if were doing it again
[timbl]
+1
[DanC]
you might look at "if we had it to do over again" as, rather "in case we're back this way again"
[Norm]
Resolved.
ACTION: NW to (re)draft his mail as a finding along those lines

2.5 Web Architecture Document Last Call

2.5.1 Heartbeat Requirement

Note publication of 5th July 2004 TR page WD See email from IJ

[Norm]

TAG thanks IJ for publishing the new WD

2.5.2 Reviews

See the 8 June 2004 Editor's Draft.

[paulc]
My review is pending. It got lost in F2F meetings and then vacation.
[Norm]
CL action continued
PC action continued
NW action continued
(all this is under 2.5.2: reviews of the arch doc)
[DanC]
the Query WG responded, Norm. They said "indeed, those things that look like functions aren't functions, in the f(x,y) = f(x,y) sense. Deal."
[Norm]
SW: Meaning and authority comments are probably the biggest
SW (of the ones I sent)
[Stuart]
http://lists.w3.org/Archives/Public/www-tag/2004Jul/0005.html
[Zakim]
DanC, you wanted to ask about moving generalities to the end... http://lists.w3.org/Archives/Public/www-tag/2004Jun/0020.html
[DanC]
ah... done. http://www.w3.org/TR/2004/WD-webarch-20040705/
[Norm]
TAG moves on to discuss SW comment #20
http://lists.w3.org/Archives/Public/www-archive/2004Jun/att-0037/webarch-ann-skw-f.html
[Stuart]
http://lists.w3.org/Archives/Public/www-archive/2004Jun/att-0037/webarch-ann-skw-f.html#_msoanchor_20
[Norm]
SW: [skw20]I think I'd make the point that protocols promote interoperability while API's promote application/implementation portability. Both are important. The two become entangled when message content contains scripts or behaviours that the recipient is expected to execute. To be interoperable the script writer has to assume the existence of a run-time environment and may have to probe for the existence of API features in order to be fully interoperable.
PC: I think the point is that APIs are different than protocols
[Chris]
i agree with norm, that is the main point
[Norm]
TBL: When characterizing either case, we're talking about the interface between two software modules. APIs are modules in the same process, protocols are greatly separated modules, perhaps not even on the same machine.
TBL: Because they are remote, the practical arrangements around protocols are very different.
TBL: APIs can rely on being updated monolithically.
TBL: It's worth noting particularly that the protocol will outlive the applications.
TBL: It's a mistake to talk about which you should do because you always have to do both
TBL: You still have APIs between software modules in the same process.
TBL: The web is better designed because it's done in terms of protocols. Some folks have tried to do APIs in this space and have found that it's a mistake.
SW: My point was that APIs aid in code portability and protocols aid in application portability.
Stuart: did I get that right?
[Stuart]
Nor... APIs aid portability, protocols aid interoperability.
[Norm]
ty
ACTION: SW to propose concrete changes to the text along these lines.
SKW 21
SKW 21: Delete "In order to communicate internally, a community agrees (to a reasonable extent) on a set of terms and their meanings."
[Stuart]
http://lists.w3.org/Archives/Public/www-archive/2004Jun/att-0037/webarch-ann-skw-f.html#_msoanchor_21
[Norm]
SW: I think it opens up problems.
DC: It opened actual problems that we've subsequently resolved
DC: It used to say "across communities"
SW: I won't push too hard, I thought it opened philosophical issues
[Chris]
that would imply a need to define 'communities' ....
[Norm]
SW: Withdraws comment.
[DanC]
wondering how Ian communicated changes to the readership, I find lots of details in http://www.w3.org/2001/tag/webarch/changes
[Norm]
SW: (SKW38) I'm not sure what point is being made
NW: This is more text that went through a lot of massaging to be acceptable
2.5.3.1 Discussion of how we moving forward.

[Norm]

SW: We have a last call document in December, how do we keep track of what comments apply to which documents
CL: Essentially, all of the comments are relevant to the last call draft.
DC: We should make some best effort to deal with all of them and then do another last call
TBL: We have to alert people who sent comments we didn't even address
DC: I disagree.
PC: You mean we won't publish a D-o-C?
DC: Right.
CL: It would be much better to be able to at least say which ones we don't think we addressed
TBL: Or if we've redraft so we can't really tell
s/redraft/redrafted/
NW: We should use "overtaken by events"
PC: We should be telling people that now, if we think it's true.
[DanC]
yes, "we should" be doing lots of stuff. I only take issue with "we must"
[Stuart]
http://www.w3.org/2001/tag/2003/lc1209/issues.html?view=normal&closed=1
[Norm]
We need to solve the issue list management problem
[DanC]
it would be _nice_ to solve the issue list management problem. we do _not_ _need_ to solve it.
[Stuart]
Last update: $Date: 2004/07/13 16:21:36 $
[Norm]
PC: We need to be able to publish a list of changes in the status section
[DanC]
DC: please let's not make that critical path
[Norm]
PC: I'm overwhelmed that you believe that process, which seems risky and crude, is going to be acceptable. I've never seen it done.
[Norm]
DC: What did you do with all the WDs before Last Call? Just did your best right.
[Norm]
DC: I've put about as much energy as I can into the current comments list
SW: I think we have to do something towards addressing Pat Hayes' comments and we have to do some work on authority and ownership.
SW: I think the C/D problem still exists in some places
DC: Anyone who's read a comment and thinks we should work on it, then we should work on it
[ChrisL]
this is a good view:
[Norm]
PC: So, between now and the f2f, TAG members should identify those comments that we should deal with. And as soon as possible after the f2f, we address those comments, and go to second last call.
[ChrisL]
http://www.w3.org/2001/tag/2003/lc1209/issues.html?view=wg&closed=1&expert=1&editorial=1&clarification=1&stateAgreed=1&stateDeclined=1&stateSubsumed=1
[Norm]
PC: The status would say that we think we've done a lot of work and the document should be reviewed a second time.
DC: Yes. A D-o-C would be gravy, but it's not critical path for me.
DC: I don't feel we've been rude to anybody.
PC: I was hypothesising, but perhaps that's not the reaction that we'd get.
PC: How long should the second last call?
DC: A month, maybe five weeks, I dunno.
[ChrisL]
given summer vacations, 6 weeks seems advisable
[Norm]
PC: That seems to put an action on the TAG members to review the comments list
[DanC]
it's about 5.6 screenfuls.
[Norm]
CL: Points us to a feasible set based on hiding editorial and other issues.
Our agenda next week will be to look at this list.
ADJOURNED

Resources:

  1. Last Call issues list (sorted by section)
  2. Annotated version of WebArch
  3. Archive of public-webarch-comment
  4. List of actions by TAG participant

The TAG did not discuss issues below this line.

3. Status report on these findings

See also TAG findings

4. Other action items

Stuart Williams for Stuart Williams and TimBL
Last modified: $Date: 2004/07/13 16:21:36 $