- From: Ian B. Jacobs <ij@w3.org>
- Date: Tue, 20 Aug 2002 11:08:45 -0400
- To: www-tag@w3.org
Hello,
The minutes from the 19 August 2002 TAG teleconference
are available as HTML [1] and as text below.
- Ian
[1] http://www.w3.org/2002/08/19-tag-summary
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
========================================================
W3C | TAG | Previous:12 Aug | Next: 26 Aug
Minutes from 19 August 2002 TAG teleconference
Nearby: Teleconference details · issues list ·
www-tag archive
1. Administrative (15min)
1. Confirm scribe and Chair (SW)
2. Roll call: DC, TB, NW, SW, PC, RF, IJ.
Regrets: CL, DO, TBL
3. Accepted 12 Aug minutes
4. Accepted this agenda
5. Next meeting: 26 Aug. Regrets SW, TBL. NW to Chair.
1.1 Completed actions
1. Action IJ 2002/08/12: Indicate that issue
URIMediaType-9 is not indicated as closed.
2. Action IJ 2002/0812: Revise arch document to
account for URI proposal; send out announcement
to www-tag in 24 hours. Make it clear that we may
not respond to all feedback. Say that we are not
committing to respond, but not to worry; open
action items won't just be dropped. Done.
1.2 Face-to-face meeting
[Ian]
DC: Feedback from our first public WD.
IJ: I'm likely to be available on Monday
before the ftf meeting.
SW: I'm also likely to be available.
PC: Don't know yet.
TB: I will be available a couple of hours on
Monday afternoon
PC: I suggest .5 day on outstanding issues we
haven't touched on in a while. (prioritized)
[DanC]
spend some time "in quadrant II". 1/2 ;-)
[Ian]
PC: One day on doc, .5 day on various issues.
[DanC]
(QII = important, not urgent)
[Ian]
SW: Any public events we need to prepare for?
(e.g., AC meeting in Nov, or tech plenary...?)
2. Technical (60min)
2.1 Review of arch doc comments
On 13 Aug Arch Doc
1. Completed Action DC 2002/08/12: Ask www-tag
for volunteers to work with TAG (and
possibly IETF) on HTTP URI stuff; CRISP.
[This action supersedes the previous action:
Ask IESG when IETF decided not to use HTTP
URIs to name protocols.] Sent. In progress.
2. Action TBL: 2002/07/15: Create a table of
URI properties.
3. Action IJ 2002/07/08: Produce WD of Arch
Doc. Harvest from DanC's URI FAQ. Deadline
30 August.
4. Internet Media Type registration, consistency of
use.
+ Action PC 2002/07/08: Propose alternative
cautionary wording for finding regarding
IANA registration. Refer to "How to Register
a Media Type with IANA (for the IETF tree)
". Not done.
See summary of comments from SW.
Writing style
[Ian]
Whether to have principles up front
(conclusions first, then justify them), or
have the primary document be the slightly
fattier form, with principles in a single-page
checklist as well.
TB: To the extend that we can dare to do less,
we increase our chances of succeeding. While I
like the idea of successive elaboration, at
the end of the day, I would be really happy
just to get the principles right. I would
argue for: Statement of principles and
supporting examples.
IJ: that sounds like what we have today:
Principles and examples.
TB: A couple of places could be trimmed.
PC: Need to agree that we are all talking
about the same audience. I agree with TB
first: coverage first. I suggest something in
the introduction to state clearly who audience
is.
DC: We definitely owe w3c WG participants
something they can read.
TB: I think that we can all agree to that.
[Agreed]
IJ: I expect to drop context into the document
later (not sure what context, but this would
be normal).
TB: Less is more in this document.
DC: How testable do we expect the assertions
of this document to be?
DC to IJ: Please try both approaches:
1. Principles up front
2. Principles in a checklist
TB: Interested by version that is "just the
facts" with fuller-bodied version as a
separate document.
Deep linking
See email from Len
[DanC]
"do nothing; leave the 'Open: ...'" <- OK by
me.
[Ian]
TB: I think the placeholder is fine. When we
address the issue, if we choose to say
nothing, that'll be fine.
IJ: I think all the issues are in the document
as placeholders.
Resolved: Leave the placeholder in place until
we address the issue.
[Norm]
I'd be quite happy with Tim's text, actually:
http://lists.w3.org/Archives/Public/www-tag/2002Jul/0118.html
Redefining URI terminology
See suggested rewrite from DanC.
[Ian]
SW: I have pushed back against the
redefinition of the terms.
TB: Two issues here that stand out:
1. What are the terms we use?
2. Range of absolute URI References with frag ids
DC: I think rename(URI Ref, URI) is pleasing,
but I can live without. But I like the
approach I took in my proposal.
TB to RF: Any news on RFC2396?
RF: The next time I get a free two hours, a
lot of things will change. See information
about URIs.
SW: I liked DC's material up until the point
"To summarize..."
[DanC]
er... "conventional..." more like
"standardized"
[Ian]
Proposed:
1. Stick to existing terminology (URI, URI
reference).
2. Use the term "absolute URI Reference";
semantically consistent with RFC2396. We
would like RF to add a BNF term for this.
RF: On range question, I disagree that URI
refs with frag ids refer to resources.
Resolved: Stick to existing terminology (URI,
URI reference). Use the term "absolute URI
Reference"; semantically consistent with
RFC2396. We would like RF to add a BNF term
for this. Work DC's language into the arch
doc.
[Roy]
I meant that I think all important resources
should have a URI sans fragment id
Range of absolute URI references with fragment identifiers
[Ian]
TB: I would be sympathetic to people providing
fragment-free URIs for important resources.
Too fuzzy when you have fragments.: One reason
is fragment-within-a-fragment
DC: What about an RDF property or a color?
TB: I can appreciate why it's convenient from
impl point of view with fragments. But you do
pay a price.
[Zakim]
DanC, you wanted to give up on s/absolute URI
reference/URI/, but to advocate the style I
used and to ask about the case of a type or a
property or a color
[Ian]
DC: So it's ok to you that something be both a
document and a color?
RF: GSM gateway, robots on the Web.
DC: These are also documents. You can GET the
representation of them.
RF: You have to come up with a rational model
why a POST to the document moves the vehicle.
NW: We've had this conversation a lot of times
before. Didn't we have consensus (other than
with TBL) that HTTP URIs could point to things
other than docs. How do we move forward on
this?
[Ian]
SW: We have this assertion from TBL that HTTP
URIs can only identify documents. But we have
lots of evidence of HTTP URIs as namespace
URIs.
DC: I have asked TBL, who says that namespaces
are documents.
SW: Another counter-example - TAG finding that
we encourage IANA to use HTTP URIs to name
internet media types.
DC: Yes, that's an interesting one.
[ian_]
IJ: I wonder whether we can pursue the path TB
pointed to: You can use URI Refs with frag ids
to point to resources; but you pay a price.
SW: If I want to point to part of a resource,
need to "promote" the identifier to a full
URI.
[DanC]
naming a part of foo#bar isn't the only way to
name parts of foo. you can say that blat is
part of foo.
[ian_]
IJ: Can I note say that
http://www.example.org/#a refers to blah and
www.example.org/#b refers to part of that?
They don't have to be syntactically related.
RF: I have discomfort of thinking of these
things identified by Abs URI Refs with frag
ids as first-class objects of the arch
document.
TB: Should we just call out the ambiguous
status of things with #?
DC: Seems to me that if you're making up some
kind of term in a dictionary, you give the
dictionary a name and a URI to a term within
it.
(same with elements in a namespace, colors in
a Pantone set).
SW: I'm concluding that there's a level of
comfort calling things you identify with a URI
+ frag id a "resource"
DC: The substantive issue seems to relate to
how to state the arch principle. "All
important resources should be identified with
a ....? "
RF: I think all important resources should be
identified by a URI. But I can't force people.
TB: I'd agree with RF if "SHOULD" is invoked.
[ian_]
TB: I am for "SHOULD" and "URI".
IJ: I am hearing:
1. MAY use absolute URI reference (with frag)
to refer to resources
2. SHOULD use URI to refer to important
resources.
IJ: What's the "difference" that makes URIs
for resources better than URI references with
frag ids for resources?
[DanC]
Only URIs work with stuff like access control,
proxies, redirection.
[ian_]
RF: You can say that "If the only thing you
are using the URI for is naming, then there is
no difference. It's only when you want to
interact with the resource that the difference
comes into play. Intermediaries within the
architecture can't affect the interpretation
of the frag id when accessed."
TB: another reason - since the interpretation
of the fragment is decreed to be a function of
the media type of the representaiton that you
get, you're not 100% sure that you can handle
it.
DC: I don't think that the media type affects
the meaning of the URI reference.
TB: If there is a frag id, the agent cannot
count on retrieving the representation (even
if one is available) because correct handling
of the frag id is a function of the media
type.
DC: If it's without a hash, it's the same
thing. RF's distinction cuts both ways.
TB: Maybe we should give up until we can come
up with something compelling to say.
IJ: I am interested in the idea that spelling
doesn't matter if the only operation is
comparison of URI thingies.
Rewrite of section 1.2
See proposal from DanC.
[Discussion of sizes of sets of infinities:
aleph, beth, ...]
DC: there are more reals than integers.
RF, SW, TB: Support for DC's language.
DC: Ok to strike the footnote.
NW: I favor striking it as well.
DC: I am not sure how to keep "valid use" in
the document. I can live with dropping it but
would rather not drop it from the planet.
[Norm]
Ian, I suggest you just leave "Each valid
use..." in S1.2 after Dan's text.
Comments from Paul Cotton on CSS
See PC's comments.
[ian_]
Strong support for PC's suggestion.
TB: I suggest we drop the model view
controller paradigm. The only embodiment of
this theory in its pure form is the java swing
toolkit. I think MVC is controversial, not
inherently related to Web architecture, and
should be excised.
[DanC]
gee... I've seen lots of deployment of MVC.
all modern word processors and graphics
programs use it, no?
[ian_]
TB: I plan to send this as a written comment.
[TBray]
No, I don't agree that much modern software is
really MVC inside; last time I checked popular
web browsers aren't.
Other editorial
[PaulC]
Ian: Did you get my editorial comments on the
Arch Doc?
IJ: No, not yet.
[ian_]
http://lists.w3.org/Archives/Public/www-tag/2002Aug/0152
http://lists.w3.org/Archives/Public/www-tag/2002Aug/0198
SW: Following pointer v. GET v. PUT/POST.
RF: We use "dereference' to emphasize that can
be PUT or GET.
DC: If you are going to post to something, you
don't get the something on your end. The value
stored in a pointer is the address of the
other thing.
RF: What about redirect?
IJ: I hear RF saying that dereference means
"use URI to interact with a representation"
and saying "get a representation" is something
else.
DC: Let's say "access a resource with a URI"
(across put/post/get).
IJ: I hear support for both (a) something that
works across put/post/get and also (a)
something for the case of GET (e.g., retrieve
a representation).
Action SW and IJ: Work on some language for
this.
------------------------------------
Remove Childist remark request from Misha Wolf
[32].
Resolved: Agreed.
----------------------------------------------
-
Request for section on architecting URIs from
Steven Livingstone
DC: There is an arch principle that WGs need
to know: you can use HTTP URis in a persistent
fashion. Some people don't believe this is
possible...
PC: Some price to pay (e.g., confusion about
date space). There is a non-normative
reference in the text to a TBL document.
[DanC]
Nope, no [Cool] in the body of
http://www.w3.org/2001/tag/2002/0813-archdoc
[ian_]
Action IJ: Put back [Cool] in persistence
section.
2.2 Postponed
1. httpRange-14: Need to make progress here to
advance in Arch Document.
IJ: We seem to be making progress on the arch doc
despite this issue. TB, is your sense this issue
could go away?
TB: No opinion.
2. RFC3023Charset-21:
1. Chris sent information to www-tag. What is
necessary to close this issue?
3. Status of URIEquivalence-15. Relation to
Character Model of the Web (chapter 4)? See text
from TimBL on URI canonicalization and email from
Martin in particular. See more comments from
Martin.
1. What should a finding look like for this?
4. xlinkScope-23
1. Priority of this?
5. Status of discussions with WSA WG about
SOAP/WSDL/GET/Query strings?
+ ACTION DO 2002/06/24: Contact WSDL WG about
this issue (bindings, query strings and
schemas) to ensure that it's on their radar.
See discussions from 24 Jun TAG teleconf.
6. augmentedInfoset-22:
+ Request from Tim Bray to decide this issue
(disposition = closed). Pushback from Simon
St. Laurent.
+ ACTION DC 2002/06/17: Talk to XML Schema WG
about PSVI. Report to tag, who expects to
decide whether to add as an issue next week.
DanC has sent email; awaiting reply from XML
Scheme WG.
7. deepLinking-25
1. Action PC 2002/07/22: Ask Henrik Frystyk
Nielsen to provide us with a precis of the
ruling. Done: awaiting reply from Henrik.
8. uriMediaType-9: Status of negotiation with IETF?
See message from DanC.
+ Action TBL: Get a reply from the IETF on the
TAG finding.
2.3 New issues?
________________________________________________
Ian Jacobs, for TimBL
Last modified: $Date: 2002/08/20 15:01:34 $
Received on Tuesday, 20 August 2002 11:12:36 UTC