- From: Ian B. Jacobs <ij@w3.org>
- Date: Tue, 21 May 2002 08:37:05 -0400
- To: www-tag@w3.org
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