Summary of 20 May 2002 TAG teleconference

Note: This is an edited version of the 20 May 2002 IRC log.

Previous meeting: 5 May 2002 [Minutes from 29 April and 5 May accepted at this meeting.]
Next meeting: 27 May. See TAG home for more meeting information.

Participants: Tim Berners-Lee (TBL), Tim Bray (TB), Dan Connolly (DC), Roy Fielding (RF), Norm Walsh (NW), Stuart Williams (SW), Ian Jacobs (IJ, Scribe)

Regrets: Paul Cotton, Chris Lilley, David Orchard


See initial agenda:

  1. Review of action items
  2. Review of TAG F2F, AC and WWW2002 participation
  3. Accept issue raised by Steve Zilles (as formattingProperties-19)
  4. Review finding on Media Types
  5. Review new finding on issue qnameAsId-18
  6. Progress, direction of architecture document
  7. Review of finding on issue whenToUseGet-7

Summary of resolutions

  1. Accept this as issue formattingProperties-19, assigned to NW (who will ask CL to be co-owner).

Action items


  1. DO: Write text about "Web as information space", to be integrated by IJ. Done.
  2. CL: Prioritize comments on Guidelines for the use of XML in IETF protocols. Done 29 April in teleconf.
  3. DC: Write more on whenToUseGet.
  4. DC: Write up limitations in draft finding for whenToUseGet-7 about limitations in SOAP
  5. DC: Add pointer to PROPfind in section on limitations/problems in whenToUseGet-7 finding
  6. DC: Point out in whenToUseGet-7 that WSDL and SOAP primer should take this into account.
  7. DC: Send a message to the XML Protocol WG comments list to point to resolution regarding GET and SOAP 1.2
  8. DC: Edit minutes of 5 May teleconf, make public
  9. TBL: Draft comments on RDF+HTML for namespace documents. Done
  10. TB: Start discussion on www-tag about nature of namespace documents, relation to qnames. Done.
    Comment from TB: There has not a lot of response; maybe that's an answer in itself, to the question of "how important is this?".
    SW: I will encourage Brian McBride to pipe up on the thread.


  1. IJ: Integrate/combine one-page summaries into arch doc. [Partly done in arch doc draft] Summaries from chapters 1 and 2 started to be integrated, but not 3 or 4. Deadline 27 May.
  2. TBL: Take uriMediaType-9 finding to IETF and IANA. TBL to contact Eastlake and Masinter, copy www-tag.
  3. TBL: Negotiate more of IJ time for arch doc
  4. CL: Add concern regarding non-western characters to the POST scenario (issue whenToUseGet-7)
  5. DO/DC/CL: Polish up DO's .1-level draft and find out what's going on with XForms. Partly done; some discussions with XForms reps at AC meeting.
  6. CL, NW: Review Character Model for the Web (last call).


  1. TBL: Take question of HTTP Query to W3C/IETF liaison (issue whenToUseGet-7)

Review of TAG F2F, AC and WWW2002 participation

SW: Comments on TAG presentations at the AC meeting or WWW 2002?
Is there anything written about the TAG session at WWW2002?
TBL: AC meeting was fairly flat as they go. The majority of comments at TAG session were about w3c process.
SW: I didn't hear any bad feedback from the AC.
DC: Perhaps comments from AC meeting on "dependencies" will re-stimulate David Orchard (who had made previous comments about dependencies among technologies).

Accept issue raised by Steve Zilles (as formattingProperties-19)

See issue raised by Steve Zilles on consistent use of formatting properties and names.

NW: Have single set of semantic properties among css, xslt, svg, ... SZ noticed recently that CSS WG has decided to rename some properties first named by the XSL WG. SZ argues that renaming properties is a bad idea.
TB: What would the TAG do here?: E.g., Would the TAG publish a one-page finding that W3C should do what it takes to get consistency?
NW: Yes, important that there be a single, unified consistent set, not slight differences among vocabularies. SZ also wants a process in place for ensuring that this is done, but that is probably out of scope for the TAG.
TB: I am in favor of a finding requiring consistent use of formatting property semantics/names. For this issue, the real question is why didn't CSS WG reuse name? Anything substantial there? If not, we can probably handle this with no work.

Resolved: Accept this as issue formattingProperties-19, assigned to NW (who will ask CL to be co-owner).

Action NW: Draft a finding for this issue. Contact CSS WG and find out why they proceeded as they did.

Review finding on Media Types

Refer to "TAG Finding: Internet Media Type registration, consistency of use".

Changes suggested by TAG:

  1. In "The Unicode encoding of a response body (XML document) is inconsistent with the value of the charset parameter in the response headers", change "response body" to "message body". And "response headers" to "message headers".
  2. Capitalize must/should/may consistently (without strong) and include reference to RFC2119. Notably, fix last paragraph.
  3. Number sections (for this an other TAG findings).

Action IJ: Revise this finding based on these comments and other editorial suggestions sent to TAG list. Send to www-tag and announce that after one week, this finding will be considered done.

Review new finding on issue qnameAsId-18

Any feedback on new draft finding on using QNames as Identifiers?

Sorry, I am readingthis docuemnt for the 1st time.
IJ: Norm, please clarify antecedent of "this usage" in section 3.
TBL: The finding makes an observation but doesn't say what to do.
NW: There are some recommendations (section 4)...
Hey, mozilla chat can now do port 6665! Thanks Dan
NW: I will make some more concise arch recommendations. I will add some specific recommendations at the end.
DC: I think the finding reflects our initial sense to warn people about problems and consequences.
Norm... you can take "perhaps" out of the ref to XSLT

Action NW: Norm will continue to edit this finding.

Progress, direction of architecture document

Refer to Arch Doc draft, $Date: 2002/05/21 12:50:59 $

Ian: I took soem of TimBL's text and tried to integretae it. Didn't get very far ... the result is not consistent.
Dan and I were talking about good bahviour stuff .. maybe there is too much for this document at this phase.
(Good style)
Currently the FAQ section has special markup and so can be hidden from view.
Given TimB's comments I pared it down. Given TimBL's I added some.
point of order: what was our homework? no agenda message was sent to www-tag, so it's not clear what version we're expected to have read
IJ: See email to www-tag about 20 may agenda.
(note homework is in the agenda on the web, danc)
TB: I'm having trouble seeing this as the web arch document.
TB, RF: Not confortable with this document.
TB: Perhaps ref doc and tutorial need to be developed in parallel.
TimBL: If this is to eb a tutorial, then there may have to be several, for diferent audeinces. (SW developers, WG members, students of CS, ...)
IJ: I am not sure that crisp expression will speak to intended audience.
TBL: There are lots of different audiences. You'll probably end up with different audiences for each (section). I agree with everyone. People have said that the DesignIssues are problematic because of spelling, lack of examples, etc.
[I prefer www-tag. let's not not *ever* say to www-tag "we already discussed that in, and ..."]
TBL: I think it's a good idea to keep this marked up so that the normative parts are very crisp.
NW: I have my reservations about having a single document serve both purposes.
TB: I've never been happy with existence of sections 3/4.: Maybe that's a signal of problem with arch document.
Hmm... do we run the risk that none of the TAG member are going to read the "fluff"?
I deny implying that the extra verbiage is "fluff" - just not sure some of it goes in this doc
Ah. good that Norm will read the fluff.
RF: I'd be happier with two documents: one tutorial, one reference manual.
("fluff" was introduced into the conversation by Ian, btw)
TBL: Crispness is important. There was a more fundamental problem I had reading this - hadn't gotten our terms right. Need to be cautious about use of terms like "resource".
What TimBL said
TBL: I think it's important to highlight that "documents" are an important subset of things we can refer to with URIs.
...I changed resource->document where I thought applied to documents but not all resources.
Ian, please include $Author: ijacobs $ along with $Date: 2002/05/21 12:50:59 $
See my edited version of an earlier version of thearch doc.
We call the things we share on the Web "resources". <-- scare-quotes are too informal. use <dfn>
with an anchor.
TBL: We don't represent telnet ports using data formats, even though telnet ports can be Web resources.
DC: I don't agree. This may be issue httpRange-14. DC: You can use an HTTP proxy to get an HTML representation of a telnet port. You can use an HTTP proxy to proxy any URI.
RF: The representation could be a flash file....
TBL: I don't believe that a telnet port is a document that can be represented. The telnet port "doesn't have a meaning."
TB: I sent a lengthy email an hour ago to that may help here.
SW: I think we need a glossary (see initial glossary in arch doc).
TBL: Things in <strong> likely headed for glossary.
IJ/DC: Don't define terms out of context; link back from glossary to context.
TB: XMLSpec has tools to highlight term definition/term reference.
NW: Style sheets could be made to generate glossary...
IJ: Three things for me to do to move forward:
  1. Read email comments
  2. Talk to RF/TBL on Friday at MIT
  3. Split into more crisp arch piece and more tutorial-like piece.
Stuart, rather than asking "are we done with ...", which noone can answer, I suggest either (a) "so, on to 1. URIEquivalence-15, unless anyone has more" or (b) any more on the architecture document?

Review of finding on issue whenToUseGet-7

Refer to Dan's finding on whenToUseGet.

DC: People sent comments (LM, SW, TB).
TBL: Mention security issue in this document. Heading like "security considerations"
TB: I think that all the things that need to be here are here. I think I agree with LM that GET-with-BODY is not essential but not harmful.
DC: It may take me a long time to work a "must" into the finding.
TB: In email example, "The latter design performed an unsafe operation (list subscription) in response to a request with a safe method (following the link from the mail message with GET). "
TB: It doesn't say "Don't do this!" So it needs a "must not" and a security heads-up.
Beware that if you use GET for things with side-effects your system may be subject to malicious attack. For example, a malicous web page publisher outside a firewall may provide a link to something which would cause someone inside the firewall unwittingly to activate a function on another system within the firewall.
SW: "All important resources should be identifiable by URI." This stands alone. The "in particular" part is operational.
TB: I liked SW's 1-2-3 list.
TBL: This goes to show that you can make something crisp and people won't understand it.
DC: At the ftf meeting, I thought that whether 2 or 3 points was editorial.
TBL: Why is "using GET" subordinate?
DC: The arch principle is that following links is safe. Propfind follows the SW principle, but it's broken.
SW: I offered two variants of the third one "following links" is loose. I"ve offered -
"users and user agents dereferencing a URI with safe access methods do not incur..."
TBL: In HTTP, dereferencing is only "GET".
Yes, I suppose s/following links/dereferencing URIs/ is an improvement.
TBL: That's true of every URI scheme that supports dereferencing to get a document.
DC: You don't incur an obligation by following a link. You can incur an obligation in other ways.
TBL: Maybe the order of DC's sentence can be inverted.
2nded: Ian to do the rest.
Action IJ: Incorporate editorial input from this call and on the list. Beautify the finding. Send to www-tag with 1-week heads-up.