W3C | TAG | Previous: 24 Feb teleconference | Next: 24 Mar 2003 teleconf

Minutes of 17 Mar 2003 TAG teleconference

Nearby: IRC log | Teleconference details · issues list · www-tag archive

1. Administrative (30min)

  1. Roll call. All present: SW (Chair), TBL, DC, DO, CL, TB, PC, NW, RF, IJ (Scribe)
  2. Accepted 24 Feb telecon minutes
  3. Acceped this agenda?

    Yes, with addition of discussion on forward references from XInclude spec

  4. Next meeting: 24 March. Regrets: TBL. At risk: CL

1.1 Meeting planning

Not discussed:

1.2 Mailing list management

Resolved:

1.3 Review of input from technical plenary (xlinkScope-23)

The TAG discussed the Tech Plenary BOF report from Henry Thompson that relates to TAG issue xlinkScope-23.

[Ian]

SW: Summary - The Hypertext CG and XML CG should constitute a small (six to eight members) joint task force to write a reqs document. Question of timeframe; a priori expected commitment to the outcome. Spirit of proposal generally accepted.
DC: I'm sort of tuned out since it looks like nothing will happen any time soon.: That doesn't bother me.
CL: Some sinking feeling at BOF that discussion will go on somewhere else.
TBL: Notes that BOF summary not that inspiring.
TB: Count me as uninspired. I don't think we'll make the tech discussion easier by having it over a reqs doc instead of over a solution. What leads anyone to suspect that there is consensus out there?
TBL: Perhaps way to move forward is to require that (1) any feature proposed must provide rationale for what cannot be done without that feature
[DanC]
I have come to appreciate requirements documents. They have a time and a place. esp in diverse communities that would like to learn to talk to each other.
[Ian]
TB: I don't think we have to do anything (as the TAG). If the two CG's think a task force is appropriate, that's great; What do we have to offer at this point?
CL: A statement that there is an architectural hole, for example.
NW: I agree with TB. I think individuals might be able to do more, but TAG may not be able to.
DC: One possibility
  1. I asked NW what he thought the ideal solution was. I think NW's position was that it would be better to pick one arbitrary choice, rather than have N floating around.
  2. TAG could pick one and market it. The TAG exists as a marketplace for attention.
DC: I am not inspired by the technical material, nor that picking one will be a substantial advance in the art. But we could be a force for unification.
TB: We tried this and convinced approximately nobody.
DC: These things take time.
TB [revision]: I think that it might be productive to invest some time to examine the technical issues and let the community know what we think. I'm not interested in the work of creating task forces.
SW: I think most of TAG would back one choice as opposed to let 1k flowers bloom. I have to communicate with two CGs.
DC: I hear CL and TB saying "let's not close xlinkScope-23 without further discussion". So I expect SW to tell CGs that we expect to address this technically in substance; so we should be connected to their discussions (somehow).
CL: The TAG cares about the results (of the task force)
Action SW: Draft note for TAG review of comments to two CGs on the tone of today's discussion.

Other feedback from Tech Plenary:

  1. DC: I heard folks say this plenary was good because folks could disagree civilly. I think the TAG had some role in establishing that norm.
  2. Some discussion on whether to hold more than one TP per year.
  3. PC reported some comments related to the Arch Doc.

DC: I haven't reviewed the tech planary IRC log for TAG suggestions, but I tried to watch for TAG stuff real-time and send mail at the time.

1.4 Other stuff

2. Technical (60min)

2.1 New issue? Message passing, a dual of shared state

Raised by DC, no resolution from TAG.

[Ian]

DC: Lots of arch discussions about REST/URIs. But there's another category of "conversations"; e.g., "Conversations and state." Voice, Web services closer to conversational interface. I think that this is discussed enough that the TAG should either include in arch doc, do a finding, etc.
RF: What's the issue?
DC: People get confused that "if it's not rest-like it shouldn't be near W3C."
TBL: The issue is that "not everything is rest."
RF: That's not an issue.
DC: I don't have text to propose to the editor right now.
SW: I wonder whether placeholder sufficient.
[DanC]
what's the difference between an issue and a placeholder in the arch doc?
[Ian]
TB: I find DC's statement of the issue kind of fuzzy. It may be on the Web but it's architecture not defined by REST. I'm prepared to accept that something could be usefully said in the arch doc.
DC: See gist of Conversations and state
CL: At a minimum we should say that scope of arch doc is limited; could be useful to point out to people when things are are outside of scope.
RF: I don't consider it an issue that there are other interaction models on the information space that is the Web.
TBL: Perhaps we should have an update on W3C Activities for the TAG There's a lot of stuff happening in Voice Activity on dialogs; they are modeling dialog paths and dialog outcomes.: Some Web Services work not using REST either.
RF: I understand the arguments; I don't understand why this is an "issue"; just add to interactions section.
SW Proposal: Put placeholder in arch doc.
Action DC: Write some text for interactions chapter of arch doc.
DC: Don't expect this week.

2.2 New issue? Forward references / decoupling specs / IRIs

Related issues: IRIEverywhere-27

[timbl]
Problems with XInclude moving to Rec include normative reference to Xpointer, charmod, and IRI spec. (Never mind parse=xml)
[DanC]
(pointer to this thing that's been pending for too long?)
[DanC]
we said IRIs are good? when/where?
[Ian]
TBL: Xpointer referenced for issues about frag id; points to charmod for XML parsing; points to IRI spec with caveats.
[Chris]
we said people should prepare for IRI, do it by copy and paste, and be ready to eratta once IRI was set in stone
this seems to be exactly whatthey did
[Ian]
TBL: XInclude spec says the WG plans to revise spec when IRI spec is finished.
[Chris]
tbl: no IRI in test suite
[Ian]
TBL: Arch questions - how to decouple the specs?
[DanC]
(reviewing our records, I find no decisions re IRIEverywhere-27)
[Ian]
TBL: No matter how the IRI spec comes out, it won't affect reviews of XPointer. But it will affect conformance of software. I think that what XInclude authors wrote in their spec may not be helpful since it may lead to operability problems when the spec is changed.
NW: I thought I had been told that I could tell Core WG that TAG was in favor of IRIs.
CL: I understood that, too.
[DanC]
We have decided *exactly* what our records say we have decided, no?
[Chris]
so, they did exactly the right think on IRI reference
[Ian]
CL: IRIs not on Rec track; but is headed to being standard.
CL: The piece that CL/MD/IJ wrote is now outdated.
Action CL/IJ: Revise this IRI summary by next week; send to www-tag.
[Norm]
Charmod references the IETF I-D IRI
[Chris]
norm - thanks
[Ian]
CL: Specs like XML Schema have similar wording; they cut and paste - don't make normative ref.
[DanC]
For the record: The TAG has not made any decisions on IRIEverywhere. Hence I'm not party to any advice anybody's giving outside the TAG on this issue. I'd much prefer actions to advise other groups waited until we'd decided the issue.
[Chris]
IRI is more mature, not yes at this point so we should trust them to do the IRI-related erattum at the appropriate time
[Ian]
[Examples of other specs doing something similar re: IRIs]
[Chris]
ok so I believesd we had at least made some decisions, even if we had not closed the whole issue
[Norm]
obviously, I thought we had general agreement as well
[Ian]
SW: RDF abstract model doc also talks about this with slightly different language
[TBray]
s/tbray/pumpkin
[Norm]
in fact, if asked before this call, I might have believed that the issue was open only because we didn't write down what we had agreedd to
[Chris]
norm, that is where I thought we were, too
[DanC]
*all* issues are only open because we haven't written down what we agreed to.
[Norm]
no, dan, there's more to it if we don't have agreeement, and you seem to be asserting that we don't
[DanC]
all the work is in the writing it down.

[No resolution]

2.3 Architecture document

[Ian]

DC: I would prefer that the 6 Feb draft (21 Feb draft) go to TR page.
IJ: I am frustrated with lack of input on this draft. Not sure how to proceed.
DC: I support TR page publication of 6 Feb draft. If you have a new intro, seek specific reviewers.
IJ: What can I do to get more input?
DC: We all have limited time; I have to balance where to turn my attention. Proposal: Request publication of 6 Feb draft on TR page.
[Roy]
I am focused on URI spec due to IETF meeting on Thursday
[Chris]
Sorry, I would need to see the differences between these before agreeing to backtrack
[Ian]
IJ: I think the 21 Feb draft is a better intro, even if not what it ultimately looks like.
DC: I'd like to see diagram of specific URI of GET(URI)-> Representation
[People keen on idea of diagram]
[Norm]
It's a heartbeat. I vote "concur" to publish any draft.
[Ian]
IJ: I hear three proposals: 6 Feb draft, 21 Feb draft, some hybrid with 6 Feb intro
SW: My preference is for hybrid.
Action IJ: Draft a new hybrid that incorporates intro of 6 Feb draft into 21 Feb version.
IJ: I will try to get TB okay before requesting publication on TR page.
SW: I am available to look at hybrid draft.

See also: findings.

  1. 21 Feb 2003 Editor's Draft of Arch Doc:
    1. Resolve to request publication of this draft (with modifications?) on TR page?
    2. Action DC 2003/02/06: Attempt a redrafting of 1st para under 2.2.4
    3. Action DC 2003/01/27: write two pages on correct and incorrect application of REST to an actual web page design
    4. Action DO2003/01/27: Please send writings regarding Web services to tag@w3.org. DO grants DC license to cut and paste and put into DC writing.
    5. Action CL 2003/0127: Draft language for arch doc that takes language from internet media type registration, propose for arch doc, include sentiment of TB's second sentence from CP10.
    6. Action TB 2003/01/27: Develop CP11 more: Avoid designing new protocols if you can accomplish what you want with HTTP. DC suggested describing GET/PUT/POST in a para each, then say "if your app looks like that, use HTTP". Proposal from TB to withdraw the proposal.
    7. See PC's email on feedback from Tech Plenary

2.4 Issues not discussed

Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2003/03/17 22:48:21 $