W3C | TAG | Previous: 6-7 Feb face-to-face | Next: 24 Jan 2003 teleconf

Minutes of 17 Feb 2003 TAG teleconference

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

1. Administrative

1. Roll call: NW (Chair), PC, DO, TB, IJ (Scribe). Regrets: CL, TBL, DC, SW. Missing: RF.
2. Accepted 6-7 Feb face-to-face minutes.
3. Accepted this agenda
4. Next meeting: 24 Feb. Regrets: IJ. Likely agenda items:
   1. Review tech plenary presentations.
   2. New issue on metadata hook?
   3. namespaceDocument-8
5. Resolved to cancel 3 March meeting as it occurs during week of Tech Plenary.
6. Following meeting: 10 March.

1.1 Meeting planning

• Completed Action PC 2003/02/06: Talk to meeting planners about May 2003 TAG schedule (noting that it overlaps with W3C track so there may be absences). (Done)

The TAG discussed conflicts on 21 May with the W3C Track.

Action IJ: Start email thread to TAG to suggest alternate May dates of 22 (All day), 23 (Morning), 24 (Morning). DO, TB, PC, NW, IJ can meet those days.

• Completed Action IJ 2003/02/06: Talk to Nov AC meeting planners to see if 14-15 ok for TAG meeting. We can meet any time according to the Keio Team, and stay at the guest house.

TB, PC, DO, NW, IJ can meet those days in November.

Action IJ: Start separate thread on tag to try to get confirmation of 14-15 November in Japan.

NW confirms that he can meet 21 (afternoon), 22, 23 in Vancouver (resolved at 6-7 Feb face-to-face).

• Completed Action PC 2003/02/06: Report TAG's tech plenary plan to tech plenary planning committee (Done).

NW: For discussion at next week's meeting.

1.2 Mailing list management

• Action SW: Send draft mailing list policy to [email protected]. (See preliminary announcement)

1.3 Other stuff

• Action IJ 2003/02/06: Fix issues list to show that actions/pending are orthogonal to decisions. IJ is working with PLH on this.
• Completed Action IJ 2003/02/06: Explain how TAG participants can edit the source of the arch document. (Done)

2. Technical

2.1 New issues?

• Site metadata hook? See email from TBL

Postponed since TBL not present. No other new issue proposals noted.

2.2 Issues

1. deepLinking-25
2. namespaceDocument-8
3. binaryXML-30

2.2.1 deepLinking-25

• deepLinking-25
  • Action TB 2003/02/06: Send URI equiv draft finding to [email protected].
  • Completed Action IJ 2003/02/06: Publish Deep Linking finding as accepted finding. See revised Deep Linking finding

Resolved: Approve revised Deep Linking finding (with IJ changes)

• Action IJ: Announce to www-tag with updated status section to highlight that this does not represent a W3C position. Ask for comments within seven days.
• After seven day review, the TAG also expects to ask the W3C Communications Team to raise awareness of this TAG finding.

2.2.2 namespaceDocument-8

• namespaceDocument-8
  • Completed Action PC, TB 2003/01/13: Write up a Working Draft that recommends a data format for namespace docs (not compulsory) and that such a document should follow the Rec track process. (Done) The initial content of the document should be taken from the RDDL challenge proposals; they are isomorphic in technical content. Please include drawbacks in the draft. See NW summary

[Ian]

TB: The document SHOULD include the pros and cons of its approach; that's in the cover email.
NW: What is next step for this document?
TB: Feedback so far has been modest in volume, but very supportive.
PC: For discussion at Tech Plenary.
TB: I'm interested in feedback from TBL (Can he live with this?) and DanC (Can we use existing HTML infrastructure?).
NW: Put on next week's agenda for DC/TBL feedback before plenary.

2.2.3 binaryXML-30

[Ian]

TB: Can we close issue 30?

IJ: No, need a finding.

DO: I think CL text is a survey but not a position. I am pleased that CL included some suggsetions.

TB: I think that what is missing is a discussion of some of the problems:

1. Do you optimize for case where both parties know vocabulary v. requirement for self-describing data.
2. Optimize for short or long message case?
3. Optimize for dense/sparse markup case?

TB: On the face, it seems that it's at least difficult to hit a sweet spot that works well for all cases.

DO: It would be useful to document the decision tree graph.

TB: I don't think people are talking about binhex-ing data.

DO: XML-as-binary v. Binary-in-XML --- are these clearly separable?

TB: I think so There are people who would like to jam multimedia into XML messages who are otherwise perfectly happy with the syntax of XML.

DO: Perhaps there's a fourth axis about including binary info in XML.

TB: I was hoping Schema would provide a lightweight way to include binary info. You have to do a lot of declaration machinery to say that a piece of content is binhexed. What I would add to the survey is solution space. I think W3C shouldn't do anything until there's a proposal that can cover a substantial part of the solution space.

Action TB: Write to www-tag with his thoughts on adding to survey.

2.3 Other issues

• URIEquivalence-15
  • Completed Action DC 2003/02/06: Publish slides on URI Equivalence. (Done)
  • Completed Action TBL 2003/02/06: Write up a proposal for a new issue regarding generic metadata hooks (related to robots.txt). Email from TBL
  • Action TB: Revised draft finding on URI equivalence bearing in mind DC presentation (slides) at ftf meeting. Deadline: 1 March. See also email from Larry Masinter on xml namespaces.
• mixedNamespaceMeaning-13
  • Completed Action SW 2003/02/06: Report to www-tag on disposition of this issue. (Done)
• xmlFunctions-34
  • Action TBL 2003/02/06: State the issue with a reference to XML Core work. Deadline 17 Feb.
• rdfmsQnameUriMapping-6
  • Action DC 2003/02/06: Propose TAG response to XML Schema desideratum (RQ-23). See input from Jonathan Marsh (forwarded by Paul Cotton).
• uriMediaType-9
  • Action DC 2003/02/06: Start discussion on [email protected], but not urgent
• RDFinXHTML-35
  • Action DC 2003/02/06: Write up a crisp articulation of issue RDFINHTML-35. [DC says - don't expect results before May 2003 meeting]
• HTTPSubstrate-16
  • Action RF 2003/02/06: Write a response to IESG asking whether the Web services example in the SOAP 1.2 primer is intended to be excluded from RFC 3205
  • See message from Larry Masinter.
• errorHandling-20
  • Action CL 2003/02/06: Write a draft finding on the topic of (1) early/late detection of errors (2) late/early binding (3) robustness (4) definition of errors (5) recovery once error has been signaled. Deadline first week of March.
• contentTypeOverride-24
  • Completed Action DC 2003/02/06: Send an email to the Voice WG that third para of 2.2.2 CR of Speech Recognition Grammar Spec is wrong regarding override of media type. (Done)
• contentPresentation-26
  • Action CL 2003/02/06: Create a draft finding in this space. Deadline 3 March.
• IRIEverywhere-27
  • Action CL 2003/01/27: Send piece that CL/MD/IJ wrote to www-tag.
• binaryXML-30
  • Completed action CL 2003/01/27: Send piece on binary XML to www-tag. (Done)
• metadataInURI-31
  • Action SW 2003/02/06: Draft finding for this one.
• fragmentInXML-28 : Use of fragment identifiers in XML.
  1. Connection to content negotiation?
  2. Connection to opacity of URIs?

2.4 Findings in progress, architecture document

See also: findings.

1. 6 Feb 2003 Editor's Draft of Arch Doc:
   1. Next TR page draft?
   2. Completed Action CL 2002/09/25: Redraft section 3 based on resolutions of 18 Nov 2002 ftf meeting. Done in 6 Feb 2003 Editor's Draft
   3. Action DC 2003/02/06: Attempt a redrafting of 1st para under 2.2.4
   1. Action DC 2003/01/27: write two pages on correct and incorrect application of REST to an actual web page design
   2. Action DO2003/01/27: Please send writings regarding Web services to [email protected]. DO grants DC license to cut and paste and put into DC writing.
   3. 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.
   4. 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.