Minutes of 20 May 2002 TAG teleconf (formattingProperties, Media Types finding, qnameAsId, arch doc, whenToUseGet)

Hello,

Minutes [1] of the 20 May TAG teleconference are available
as HTML and quoted below as text.

  _ Ian

-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447


            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

Agenda

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

Closed:

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.

Open:

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).

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

Review of TAG F2F, AC and WWW2002 participation

[Ian]
      SW: Comments on TAG presentations at the AC
      meeting or WWW 2002?

[DanC]
      Is there anything written about the TAG session
      at WWW2002?

[Ian]
      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.

[Ian]
      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?

[DanC]
      Sorry, I am readingthis docuemnt for the 1st
      time.

[Ian]
      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)...

[TBray]
      Hey, mozilla chat can now do port 6665! Thanks
      Dan

[Ian]
      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.

[TBray]
      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:32:57 $

[timmit]
      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.

[DanC]
      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

[Ian]
      IJ: See email to www-tag about 20 may agenda.

[timmit]
      (note homework is in the agenda on the web,
      danc)

[Ian]
      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.

[timmit]
      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, ...)

[Ian]
      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.

[DanC]
      [I prefer www-tag. let's not not *ever* say to
      www-tag "we already discussed that in
      tag@w3.org, and ..."]

[Ian]
      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.

[DanC]
      Hmm... do we run the risk that none of the TAG
      member are going to read the "fluff"?

[TBray]
      I deny implying that the extra verbiage is
      "fluff" - just not sure some of it goes in this
      doc

[DanC]
      Ah. good that Norm will read the fluff.

[Ian]
      RF: I'd be happier with two documents: one
      tutorial, one reference manual.

[DanC]
      ("fluff" was introduced into the conversation by
      Ian, btw)

[Ian]
      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".

[TBray]
      What TimBL said

[Stuart]
      +1

[Ian]
      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.

[DanC]
      Ian, please include $Author: ijacobs $ along
      with $Date: 2002/05/21 12:32:57 $

[timmit]
      See my edited version of an earlier version of
      thearch doc.

[DanC]
      We call the things we share on the Web
      "resources". <-- scare-quotes are too informal.
      use <dfn> with an anchor.

[Ian]
      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
      tag@w3.org 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.

[DanC]
      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?

[TBray]
      http://lists.w3.org/Archives/Member/tag/2002May/
      0039.html

Review of finding on issue whenToUseGet-7

Refer to Dan's finding on whenToUseGet.

[Ian]
      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.

[timmit]
      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.

[Ian]
      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".

[DanC]
      Yes, I suppose s/following links/dereferencing
      URIs/ is an improvement.

[Ian]
      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.

[DanC]
      2nded: Ian to do the rest.

[Ian]
      Action IJ: Incorporate editorial input from this
      call and on the list. Beautify the finding. Send
      to www-tag with 1-week heads-up.

Received on Tuesday, 21 May 2002 08:39:28 UTC