W3C | TAG | Previous: 30 Jun teleconference | Next: 14 July
2003 teleconf
Minutes of 7 July 2003 TAG teleconference
Nearby: IRC log | |Teleconference details · issues list · www-tag archive
1. Administrative
- Roll call: SW (Chair), DC, DO, NW, TB, IJ (Scribe). For the discussion
about contentTypeOverride-24, Jerry Carter from the Voice WG attended.
Regrets: TBL, RF, PC. Missing: CL
- Tentatively accepted minutes of 30
Jun teleconference with changes requested by Chris Lilley. Awaiting
confirmation from Chris Lilley.
- Accepted this agenda
- Next meeting: 14 July. Likely regrets: NW.
- Face-to-face meeting agenda
SW: I count on having an agenda for the TAG by next week.
2. Technical
- Review of text from Voice Browser
Working Group and finding (contentTypeOverride-24)
- Review of comments on finding for
whenToUseGet-7
- TAG comments on SW draft of finding for issue
metadataInURI-31
2.1 Review of text from Voice Browser Working Group (contentTypeOverride-24)
[Ian]
- JC: Thanks to SW and IJ for discussions last week and for comments on
text. One point in contention was use of "type" attribute overriding
server headers. We've concluded that that was inappropriate and the new
language makes the headers authoritative. We are taking a direction
that the HTML WG seems to be going with XHTML 2.0: using "type" as a
kind of preference (accept header). Once representation returned, if no
header sent, then type serves as a strong hint. Most of SW/IJ comments
have been incorporated. There are a few remaining minor issues
open.
- TBray: Sounds like the results are clean and sensible. We should all
be happy.
- [JC gives quick overview]
- TBray: Looks fine to me.
- DC: Please clarify the semantics of the table.
- JC: First three lines provide context; fourth line provides desired
behavior.
- DC: Declared media type, if I understand, is some combination of
server type and preferred type.
- IJ: I had initially said that dual usage of "type" was unnecessary;
just use it as a preference.
- [TBray]
- I see potential editorial quibbles, but the thrust is architecturally
sound, are we micro-managing?
- [Ian]
- IJ: But SW made a good point that it's cheaper to verify something's
type than it is to determine the type of something.
- DC: I"m not comfortable with "alleged media type". I'd be most
comfortable with a test case. You are headed for PR?
- JC: Yes, this is the only outstanding issue.
- DC: Do you have test cases for this behavior?
- JC: I think so. I would need to look at details. We have about 200
tests. I believe there's a test for this; I"d have to be sure.
- DC: What would make me feel most comfortable is a test that shows a
server returning text/plain and an implementation noticing the
error.
- JC: That's a reasonable request. There are probably 2-3 tests one
would run for this (i.e., each of the special cases).
- DC: It's not critical that the TAG endorse the final text. We were
asked our opinion, we gave it, they tweaked their spec, and everybody's
happy.
- JC: Outside of this discussion, I owe some personal feedback
regarding test cases. But I think the issues between the Voice WG and
the TAG are resolved.
- SW: I'd like to record our thanks to the Voice WG!
- TB, DC: Absolutely.
- The TAG wishes the Voice WG good luck!
[JC leaves]
More discussion on reviews of Client handling of
MIME headers
- Action CL, NW 2003/06/30: Read the draft finding by 7 July. NW
Done
- Completed action IJ 2003/06/30: Announce on www-tag that we expect to
approve this finding in a week or so. Last chance for comments (Done)
- Completed action IJ 2003/06/30: Ping SMIL IG about this finding, which
refers to architectural error in SMIL 2.0 (Done).
- See original summary
of comments
- Comments
from Norm Walsh
- See comments
from Philipp Hoschka and comments
from Rob Lanphier
- See suggested
editorial changes from TBL
- Comments
from Stuart Williams
[Ian]
- Comments
from Norm Walsh
NW: My comments were mostly editorial nits; fine on the whole.
NW: In section 6, bullet 3, I would support "MUST NOT": "Specifications
MAY include hints about server headers but SHOULD NOT include
requirements that a client override these headers without involving the
user."
DC: Seems strange to constrain the spec. If you don't have the user's
consent, you can't hold them responsible. I don't think this is the
best advice we can give to spec writers .If a user agent wants to do
something different than the published protocol, they have to do so
with the consent of the user, otherwise they are not acting on behalf
of the user.
TBray: Any time somebody writes this sort of thing in a spec, they can
be sure they'll get static from the TAG.
DC: Will we read every spec? We can just say "The server mime type is
authoritative."
TBray: Then we should say nothing about what specs do..."SHOULD" is
misleading.
NW, DC: Change to MUST NOT in bullet 2.
IJ: I can live without bullet 3 since section 5 covers this.
- Resolved: In section 6 of finding, drop
bullet 3 and to change SHOULD NOT to MUST NOT in item 2.
Comments
from Rob Lanphier
- TBray: I think some of RL's comments about servers are useful, e.g.,
default content type is harmful.
- IJ: Seems like a reasonable addition to talk about how to address
this issue in practice.
- DC: Don't talk about "harmful", talk about "risks of default content
type" The right answer in case of misconfigured server is not to sweep
it under the rug.
Suggested
editorial changes from TBL
- TBray: Unless TBL can provide some examples of the impact on
programmers, what's the utility of this?
- DC: To me this look editorial and is not a huge improvement. Putting
"the" in your face doesn't help things. I'd prefer that IJ return to
TBL and ask for more motivation.
- TBray: I like TBL's example of showing how even self-describing
content not sufficient (or may provide wrong info) about author's
intent in some cases.
- Action IJ: Produce a new draft of the
finding on MIME headers that takes into account comments from Rob
Lanphier, TBL, NW, SW (editorial), and above resolution.
Comments
from Stuart Williams
- SW: I'd prefer "state of the resource" over "meaning of the
resource". I think that "meaning of the resource" is more complex than
its state. Also, the second security example didn't seem so credible to
me.
- DC: "State" of the resource is ok.
- IJ: I'll produce a new draft for next week.
- [TBray]
- Ian: I think asked you to send a note to the SMIL folks saying
"thanks, we're taking your input seriously & will redraft"
Action IJ: Follow up with SYMM IG saying
we'll take into account input and produce new draft of this
finding.
Summary of actions:
- Action DO: Send text that DO and Noah M.
can agree to to tag@w3.org.
- Action IJ: Produce new draft of finding
with (1) change based on LM comment, (2) text from DO/NM (3) don't
address PUT in this finding, but add comment about new issue putMediaType-38
(second point in summary
of comments).
[DanC]
- (hmm... no story atop 4
July 2003 draft of finding)
- [Ian]
- DC: I think the finding may be getting too long. I was hoping for
three paras that say "Don't peek into URIs."
- "People and software making use of URIs assigned outside of their own
authority (i.e. observers) MUST NOT attempt to infer properties of the
referenced resource except as licensed by relevant normative
specifications or by URI assignment policies published by the relevant
URI assignment authority."
- SW: Can one make use of information published by W3C (in a
policy)?
- DC: Shorten 3 to "Don't peek inside the URI." It's always safe to not
peek inside the URI. On Scheme component designators and wsdl
components....
- [DanC]
- the W3C tech reports naming policy isn't based on the URI alone.
there's no guarantee that http://www.w3.org/TR/2003/WD-snort-20040707
is a W3C working draft. If you know that it is a WD somehow, you can
learn stuff from the URI. but you can never just peek into the URI
alone.
- [Ian]
- DO: DC's point (don't peek in URIs) is in conflict with what some
groups are trying to do.
- SW: Does this draft need more work before sending to www-tag?
- DO: I agree with DC that it seems a little long.
- NW: If I understand DC correctly, sounds like DC is saying that if I
know XQuery is a Working Draft, then I can find meaning in WD in URI.
If I saw a URI ending in "WD-".... could I infer that it's a WD?
- DC: No You have to look at the TR page as well. Once you have found
something on the TR page, there's quite a bit you can go on. If you
start from the TR page and find the URI, that's fine. But if you find
the URI on the floor somewhere, you can't go on that alone.
- [Norm]
- That http://www.w3.org/TR/wd-foo
exists does not imply foo is a WD unless and until it appears *as a
link* on the TR page.
- [Ian]
- DC: Just don't peek in the URI.
- DO: I don't want the finding written that way.
- DC: A story would be useful. If you want to treat the entire topic,
then start with a story. It's not clear why someone wants to read all
this stuff. I don't think IJ is hot on the trail of a story. I don't
think this comes up very often...may not deserve a real story.
- SW: I will take a crack at writing something short before floating on
www-tag.
- NW: Perhaps DO could write a couple of paragraphs to motivate why one
would want to do this.
- [DanC]
- which wsdl group posting?
- [Ian]
- DO: I'll write up something in response to SW's draft.
- DC: I'm not sure putting burden on SW is appropriate. Maybe just send
what you've got and say there isn't agreement. Promote third bullet to
abstract.
- DO: Amazon publishes policy for query parameters.
- DC: Perhaps cheapest approach is to open up to community.
- [DanC]
- treating the whole forms interface convention is more than I would
have expected for a finding on issue metadataInURI-31
- [Ian]
- DO: Where do others stand on this?
- NW: I'm definitely on the fence. I think there's a lot of merit in
"don't look inside the URI", but I understand what the WSDL WG wants to
do.
- DC: Don't put version numbers in URIs was the original question.
- TBray: I think the answer is still "probably not"
Action SW: Create new draft based on input
today and send to www-tag.
Action DO: Send rationale about why WSDL WG
wants to peek inside the URI.
2.4 Findings the TAG did not discuss
See also: findings.
Next steps on these findings:
2.3 Architecture document
27 June 2003 Working Draft of Arch
Doc published.
- Discussion of text
sent by David Orchard about extensibility.
- Completed action PC 2003/06/16: Send second draft of AC announcement
regarding TAG's last call expectations/thoughts and relation to AC
meeting feedback (Done).
- Action RF 2003/06/02: Rewrite section 5. Section 5 is expected to be
short.
- Action IJ 2003/06/16: Attempt to incorporate relevant bits of "Conversations and
State" into section to be produced by RF.
About Paul's
second draft of comments to AC.
- [DanC]
- the question of who sends it to ac-forum is a good one
- [TBray]
- Issue is: who sends this thing, and to whom
- SW: want's TimBL's sign-off. I would want to sign it from both of
us.
- [Ian]
- DC: Don't put TBL's signature at bottom of something he hasn't
read.
- TBray: I propose that SW find TBL and get him to sign off.
- [TBray]
- Action SW: Try to get TimBL to sign off
on Paul's text. If SW able to reach TBL, SW/TBL send to AC as
co-chairs. If not, have IJ send on behalf of TAG.
- [DanC]
- so RESOLVED
2.4 Issues the TAG did not discuss
- 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. Due first week of March.
- RDFinXHTML-35
- mixedUIXMLNamespace-33
2.5 Issues with action items
- uriMediaType-9
- IANA appears to have responded to the spirit of this draft (see email
from Chris Lilley).What's required to close this issue?
- Action CL 2003/05/05: Propose CL's three changes to registration
process to Ned Freed. [What forum?]
- 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 w.r.t. Web services.
- xlinkScope-23
- See draft,
and SW
message to CG chairs.
- Action CL 2003/06/30: Ping the chairs of those groups asking
for an update on xlinkScope-23.
- binaryXML-30
- Action TB 2003/02/17: Write to www-tag with his thoughts on adding
to survey.
- Next steps to finding? See summary
from Chris.
- xmlFunctions-34
- Action TBL 2003/02/06: State the issue with a reference to XML Core
work. See email
from TimBL capturing some of the issues.
- siteData-36
- Action TBL 2003/02/24 : Summarize siteData-36
2.6 Issues the TAG intends to discuss at face-to-face meeting
Identifiers
Qnames, fragments, and media types
RDDL, namespace documents
- namespaceDocument-8
- Action TB 2003/04/07: Prepare RDDL Note. Include in status section
that there is TAG consensus that RDDL is a suitable format for
representations of an XML namespace. Clean up messy section 4 of RDDL
draft and investigate and publish a canonical mapping to RDF. See
TB's 1 June
version.
- Action PC 2003/04/07: Prepare finding to answer this issue,
pointing to the RDDL Note. See comments
from Paul regarding TB theses.
- Refer to draft TAG opinion
from Tim Brayon the use of URNs for namespace names.
- RF: Folks assume that because the specs say so, URNs will be
persisitent. But persistence is a function of institutional
commitment and frequency of use.
2.7 New issues?
The TAG expects to discuss these on 14 July.
- Visibility
of Web Services, raised by Mark Baker
- Character
model conformance, raised by TBL
- Meaning
of URIs in RDF documents, raised by TBL
3. Other actions
- Action IJ 2003/02/06: Modify issues list to show that actions/pending
are orthogonal to decisions. IJ and PLH making substantial progress on
this; hope to have something to show in May.
Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2003/07/07 23:33:41 $