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:
- Review of action items
- Review of TAG F2F, AC and WWW2002
participation
- Accept issue raised by Steve Zilles (as
formattingProperties-19)
- Review finding on Media Types
- Review new finding on issue qnameAsId-18
- Progress, direction of architecture document
- Review of finding on issue
whenToUseGet-7
Summary of resolutions
- Accept this as issue formattingProperties-19, assigned to NW (who will
ask CL to be co-owner).
Closed:
- DO: Write text about "Web as information space", to be integrated by
IJ. Done.
- CL: Prioritize comments on Guidelines for the use of XML in IETF
protocols. Done 29 April in teleconf.
- DC: Write more on whenToUseGet.
- DC: Write up limitations in draft finding for whenToUseGet-7 about
limitations in SOAP
- DC: Add pointer to PROPfind in section on limitations/problems in
whenToUseGet-7 finding
- DC: Point out in whenToUseGet-7 that WSDL and SOAP primer should take
this into account.
- DC: Send a message to the XML Protocol WG comments list to point to
resolution regarding GET and SOAP 1.2
- DC: Edit minutes of 5 May teleconf, make public
- TBL: Draft comments on RDF+HTML for namespace documents. Done
- 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:
- 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.
- TBL: Take uriMediaType-9 finding to IETF and IANA. TBL to contact
Eastlake and Masinter, copy www-tag.
- TBL: Negotiate more of IJ time for arch doc
- CL: Add concern regarding non-western characters to the POST scenario
(issue whenToUseGet-7)
- 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.
- CL, NW: Review Character Model for the Web (last call).
Withdrawn:
- TBL: Take question of HTTP Query to W3C/IETF liaison (issue
whenToUseGet-7)
- [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).
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.
Refer to "TAG Finding:
Internet Media Type registration, consistency of use".
Changes suggested by TAG:
- 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".
- Capitalize must/should/may consistently (without strong) and include
reference to RFC2119.
Notably, fix last paragraph.
- 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.
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.
Refer to Arch Doc
draft, $Date: 2002/05/21 12:50:59 $
- [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:50:59 $
- [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:
- Read email comments
- Talk to RF/TBL on Friday at MIT
- 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
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.