- From: Ian B. Jacobs <ij@w3.org>
- Date: Mon, 15 Jul 2002 22:42:38 -0400
- To: www-tag@w3.org
Hello,
Minutes of the 15 July 2002 TAG teleconf available
as HTML [1] and as text below.
- Ian
[1] http://www.w3.org/2002/07/15-tag-summary
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
========================================================
W3C | TAG | Previous: 8 Jul | Next: 22 July | IRC log
Minutes of 15 July 2002 TAG teleconference
Nearby: Teleconference details · issues list ·
www-tag archive
1. Administrative
1. Roll call. All present except regrets from CL:
TBL, TB, DC, NW, DO, SW, PC, RF, IJ
2. Accepted this agenda
3. Next meeting 22 July.
4. Accepted 8 July minutes
5. Confirm status of completed actions
1.2 Completed actions?
1. IJ: Find out whether the W3C Comm Team expects to
have a publishing moratorium in August. (Awaiting
reply).
2. Technical
* 2.1 Architecture document
* 2.2 Qnames as identifiers
* 2.3 Consistency of formatting property names,
values, and semantic
* 2.4 httpRange-14
* 2.5 Postponed
* 2.6 New issues
2.1 Architecture document.
1. ACTION TBL 2002/05/05: Negotiate more of IJ time
for arch doc
TBL: Keep on back burner for 30 days. IJ will
have more time in the fall.
TB: What provoked this was decision last week to
have first public WD soon. Some question about
IJ's availability being a roadblock. Anything can
we do? This issue is material to getting a spec
out.
DC: I would rather process doc go to sleep for 2
months than TAG
NW: +1
DC to TBL: Please push this at the AB
face-to-face meeting this week.
2. ACTION RF 2002/06/24: Write a paragraph on
technical and political aspects of URIs and URI
References.
RF: I touched on this on mailing list, but this
para is 2nd priority to the URI spec itself.
3. COMPLETED Action TB, DC 2002/07/08: Propose text
for section 1.1 (URI Schemes).
4. Action CL 2002/07/08: Propose text for section 2
(Formats). Deadline 30 July.
5. Action DC 2002/07/08: Ask Michael Mealing when
IETF decided not to use HTTP URis to name
protocols. DC has sent email, awaiting reply.
TB: What's going on with different answers from
Mark Baker, Keith Moore, and Michael Mealing?
DC: Sometimes hard to get an answer from the
IETF.
6. Action IJ 2002/07/08: Produce WD of Arch Doc.
Deadline 30 August.
On the table of URI schema properties (proposed by SW).
<Ian> IJ: I have put SW's table in arch doc appendix
for now.
<Ian> TBL: The important arch point is that these
properties vary.
<Ian> DC: I disagree with the way the table answers
the question.
<Ian> TBL: Disagreeing with column names or cell
contents?
<Ian> DC: I disagree with TBL's conclusion that http
points to document.
<Ian> TBL: My opinion is that you can't put "any"
there since there's an open issue.
<Ian> TB: I think this belongs in an appendix.
<Ian> SW: I'm fine with people disagreeing on the
contents of the table (for now)
<Ian> TBL: "Decentralized" is a bit of a political
thing...
<Ian> DC: Quite.
<Ian> TBL: Subject to ongoing discussion as to the
contents, I think the table is a useful thing. I'd
like to generate table from RDF.
<Ian> Action DC: Regenerate this table from RDF
(looking closely at contents of cells).
<Ian> TB: I think it's worth discussing the role this
thing takes in the arch document. I've seen the core
of the arch document to be the assertions. One key
arch principles is that you shouldn't invent URI
schemes. One good reason is that software is expected
to handle them. I'm wondering what the reason is for
having a table in the arch document. I think the
table is useful (somewhere). Does it have normative
force? It will change over time.
<Ian> TBL: I think this is as normative as the rest
of the document. We should say you shouldn't
re-invent the wheel.
<DanC_> (actually, you don't have uuid, timbl; it's
not registered. Er..hmm... maybe it is, under urn:)
<Ian> TBL: If you are proposing a new URI scheme that
has properties of scheme s, then use s.
<Ian> TB: So, the arch doc should include a list of
some well-known URI schemes with properties to aid
people in not inventing new ones?
<Ian> TBL: Yes, also to raise attention about some
schemes.
<Ian> TB: Ok, that sounds plausible to me.
<Ian> IJ: I was going to suggest leaving in an
appendix for now, and deciding later whether to pull
out.: Good to have clarification on the meaning of
the columns.
<DanC_> [note to self, for action: a possible
corrollary of table with props: if you want an admin
hierarchy, use DNS.]
<Ian> TB: "Resource state dynamics"?
<Ian> TBL: Is this just persistence?
<DanC_> [note to self: "fixed content resource"?
column]
<Ian> TBL: Column heads: Persistence and
Dereferenceability
<Ian> IJ: What values would one find for each column
(where possible to enumerate)?
<DanC_> [note to self: re static: are there any
future network messages that can show a different
state of the resource? no, not for news: articles]
<Ian> TB: What about text I submitted?
<Ian> DC: I disagree on the first sentence.
<Ian> " 2. A URI identifies an abstraction for which
there is a time-varying conceptual mapping to a
(possibly empty) set of representations that are
equivalent."
<TimBL> http://www.w3.org/DesignIssues/Generic.html
<Ian> DC: Varies by more than time.
<Ian> TB: Why is time specially distinguished?
<Ian> RF: People keep forgetting it.
<TimBL> time, language, representation, ....
<Ian> DC: Not sure if I definitely object.
<Ian> PC: If DC's concern is that people forget that
is to put in a second sentence.
<DanC_> See my www9 presentation on this mapping
between URIs and content.
<Ian> TBL: I'd like parameters to be tabulated.
<TimBL> Table head: What can resoirce vary under?
<Ian> TB: I think DC's objection is correct. Leans to
heavily on time. "A URI identifies an abstraction for
which there is a conceptual mapping to a (possibly
empty) set of representations that are equivalent.
May vary ...."
<Ian> Action TB: Clarify first sentence.
<DanC_> -> http://www.textuality.com/tag/s1.1.html
<Ian> DC: A lot of naming issues are justified
architecturally by economics. E.g., costly to deploy
new URI schemes ubiquitously.
<Ian> TB: My text says that.
<Ian> DC: Why have absolute naming in the first
place? It might be worthwhile to tell story about how
absolute email addresses came to be. Used to be the
case that you have to go through several machines
(susie!bob!ian...) to get to ian.
<TBray> aaah... watmath!decvax!anywhere as I
recall...
<Ian> TBL: Root emerged. The Web tree-ified.
<Ian> DC: The point is that URIs serve this need in
communication (to refer to things).
<Ian> TBL: DC explaining why it's useful to have
absolute names - why absolute URis mean the same
thing wherever you are.
<Ian> TB: Principle - "Absolute addressing is better
than context-sensitive addressing."
<Ian> DC: More subtle than that - cheaper....
<Norm> The ability to provide absolute addressing is
better...
<Ian> DC: This is the adopted principle - that is the
way it is.
<Ian> Action SW: Write down this arch principle.
<Ian> PC: The story DC started to tell (about email
addresses - routing in email address). Doesn't this
go against another arch principle - shouldn't be
centralized name serverse?
<Ian> DC: Yes, there is a subtlety here. There is a
tension.
<Ian> TBL: DNS as weakness in Web.
<Ian> PC: We all decided that DNS was better.
<Ian> SW: If you are going to assert that DNS is a
weak point, would you be bound to propose a
substitute?
<Ian> DC: The ideal URI scheme (from one end) is that
everyone generate random numbers. But a pain since
you can't write them down, hard to search through.
(See efforts by Freenet folks) So DNS is easier. TBL,
you have to write the story, not just expect people
to buy it.
<DanC_> gold star for Bray providing text for 1.1,
btw.
Steps to first public Working Draft.
<Ian> TB: How do we get from here to first public WD
15 August?
<Ian> DC: I'm happy to have IJ chew on text until
early August and then ship it.
<TimBL> "[DNS centralization and exploitation] does
serve as a good illustration of the way a single
centralized point of dependence put a wrenchin the
gears [...] and be exploited [...]for power and
profit ---- "Weaving the Web" p129
<Ian> DC: I have no lower bound on quality.
<Ian> TB: I do have a lower bound on quality.
Press release for first public Working Draft?
<Ian> IJ: Today at Comm Team talked about press
release for first public WD.
<Ian> DC: No thank you.
<Ian> DO, PC, TBL, SW: I agree with DC.
<Ian> IJ: I told Janet document would be rough.
<Ian> TB: You could achieve higher quality by
removing partial sections.
<Ian> DC: You make it sound like shorter is easier,
but that's not my experienc3.
<Ian> SW: Where would we have to be happy with in
order to say ok to a press release?.
<Ian> TB: If we do something that has WD on the top,
it will get press coverage anyway.
<Ian> DC: If we do a press release, I'll have to take
press calls.
<Ian> PC (changing mind): I'm fine if JD wants to do
a press release on this. Assuming she doesn't ask for
testimonials, I think we just need to be sure that
the document indicates where we have made decisions,
where we have isuses, and where we need more input.
* DanC_ struggles to accept the role of the press in
his work; may just never get it thru his head.
<Ian> NW: I think we should concentrate on what we
need to do and let the press take care of itself.
<Ian> TBL: Publish arch doc with links to findings,
and indicate clearly that this is a strawman.
<Ian> TB: If W3C thinks it's appropriate to do a
press release, then I would support this.
<Ian> IJ: Objections to a press release?
<Ian> DC: Yes.
<Ian> TBL: If DC were to be absolved from press duty,
would DC still object?
<Ian> DC: Yes.
<Ian> RF: I can't agree to a press release until I
know what's in the document. (Both press release and
arch document)
<Ian> TB: I agree with RF: if we agree based on
document, and we agree to press release, seems ok to
me.
<Ian> SW: So, for IJ report to Comm Team:
1. In principle, agreement.
2. TAG wants to see where it is and to see press
release text.
2.2 Qnames as identifiers
1. Action NW 2002/06/24: Follow up on Rick Jelliffe
comments/proposal. Done; finding revised.
<Ian> NW: XPointer rejection almost dissolves the
finding. Some specs require application-specific
out-of-band mechanism, some do not. I think the
finding is useful for what it outlines, but I don't
think we have ground to stand on. XPath uses in-scope
namespaces successfully.
<Ian> DC: But people don't expect to pull it out of a
doc and use somewhere else. They do have that
expectation for URIs and URI references. The roles of
URIs architecturally is to be context-free.
<Ian> NW: I'm suggesting that the finding has no
recommendations to make. It has become even more just
a bunch of red cones around a hole in the
architecture. "Don't walk near here."
<Ian> DC: Fine.
<Ian> TB: Still useful.
<Ian> TBL: Yes, red cones are useful.
<Ian> NW: I will therefore republish with no
recommendations.
<Ian> DC: Can you tell the story about the contrast?
<Ian> NW: Yes.
<Ian> TBL: What about special styling for stories?
<Ian> IJ: I don't think necessary. Just write well.
<Ian> DC: I think not useful for findings but for
arch document, yes.
<Ian> NW: I will add material up front that this
finding has no recommendations to make. Just
identifies a nasty singularity in the space-time
continuum.
Action NW: Revise and publish Qnames as identifiers
finding.
2.3 Consistency of formatting property names, values, and
semantics
Finding updated by NW
<Ian> NW: I think that this one is done, too. I
republished today. I think it's ok to state arch
principles without saying how. I did both of actions
that CL requested.
<Ian> DC: I think we notify www-tag that we're done.
<Ian> IJ: What's the difference between saying
one-week appeal and no appeal?
<Ian> DC: If you're reading this, and 7 days after
publication, look around. If later than 7 days, then
you are more certain that stable.
<Ian> IJ: Put this in status section then, not as
critical for annoucnement to www-tag.
2.4 httpRange-14
1. httpRange-14: Need to make progress here to
advance in Arch Document.
<Ian> DC: Principle of minimal constraint is on my
side.
<TimBL> Your side being, "any?"
<Ian> RF: I've been talking about this on www-tag for
last week, under heading resource and representation
(see email from RF).
<TimBL> I though that I forced DanC into a
contradiction starting from "Any".
<Ian> TB: I think RF's responses are dense and
well-considered.
<Ian> DC: RF, so you conclude I can point to my car
with an HTTP URI?
<Ian> RF: Yes.
<Ian> TB: Important to consider the consequences of
the decision. Are there any meaningful consequences?
<Ian> DC: The irony is that, in principle, no, but
there are some practical consequences. I would
recommend that people don't point HTTP URIs at their
car.
<Norm> "Your gun, your bullet, your foot" -- that
quotation is my favorite memory of a VM/CMS internals
course I took once upon a time
<Ian> DC: I'm convinced that there are negative
practical things to do in this area.
<Ian> TBL: I have in my mind a consistent model where
HTTP URI points to a document about a car. I don't
have a consistent system where HTTP URIs designate
cars. The moment I retrieve something, it has
something like a title. Therefore a work, not a car.
The Dublin Core says that title is the title of the
resource, not the representation.
* Ian missed RF comment about whether Dublin Core was
referring to representation or resource.
<Ian> DC: When people use HTTP URIs to point to a w3c
tech report, they mean "title" of the resource, not
the representation. HTML doesn't have the ability to
say 'this is the title of the resource you just
referenced'. But RDF lets you do this.
<Ian> RF: Yes.
<Ian> TB: What would you change in the arch document?
<Ian> RF: What does it mean to do a POST?
<Ian> RF repeats: A representation is not a resource.
<Ian> DC: You post to a car, not a car.
<Ian> RF: Yes, you can post to a car.
<DanC_> one posts a document to a resource
<DanC_> Ian, issue 15 came up in the arch doc
drafting, yes?
<Ian> (responding to DC:) Yes, in section 1.1:
Whether two strings are different spellings for the
same URI. [TAG issue URIEquivalence-15]
<DanC_> TimBL, you're answering "where in the RDF
specs does this matter?", not "where in the arch doc
does this matter?"
<Ian> TBL: How affects the arch document - the table
of properties of URI schemes.
<Ian> NW: I agree that this is a problem for RDF, but
not Web architecture.
<Ian> TBL: If I can't build RDF on top of it, then
the Web architecture is insufficient.
<Ian> TBL: Show me the URI for a car.
<Ian> RF: I have URIs for robots in the MIT media
lab.
<DanC_> my car: http://dm93.org/y2002/myCar-232
<Ian> TBL: You can say "this is a view of what robot
sees" etc., but these are all Web pages. I have a
problem with metadata - talking about the thing and
the representation of the thing.
<Roy> content negotiation has same issue
<Ian> DC: HTTP last-modified means "last time web
master updated the view of my car through HTTP"
* Norm scratches his head
<TBray> It seems like there is an important class
distinction between resources which are in fact
pieces of electronic information and those which are
symbolic stand-ins for things like cars
<Ian> TBL: Layered world - properties that apply to
car and to representation of car.
<TBray> it seems like RDF should be able to talk
meaningfully about this distinction
<Ian> RF: there are some headers in HTTP that only
refer to the representation. There are some fields
that refer to the resource only (e.g., alternates).
<TimBL> s/Layered world/Youare now falling into the
lcassic trap of the layered world/
<DanC_> No, no layered world.
<Ian> RF: You cannot say that the author of the file
is the same as the author of a resource. You may have
five authors of five representations that represent
the same resoruce. If RDF cannot support this, then
RDF cannot support resources.
<Ian> DC: I think not an error in either. I think
TimBL wishes he had an axiom on top of RDF but it's
not there.
<Ian> TBL: Can I use FTP URI to point to a car?
<Zakim> -TBray
<Ian> RF: HTTP is more powerful than FTP.
<Ian> DC: My position is independent of scheme; use
any scheme you want to refer to my car.
<TimBL> Dan, I use <mailto:foo@foo.fog> to refer to
your car.
<TimBL> Dan, I hereby use <mailto:foo@foo.fog> to
refer to your car.
<Ian> DC: yes, presuming you own foo.fog
<DanC_> [I stipulate that TimBL owns foo.fog]
<Ian> TBL: Who owns foo@foo.fog?
<TimBL> Who owns <foo@foo.fog>?
<Ian> DC: I own the car.
<Ian> TBL: I think the Web rests on the assumption
that mailto identifies a mailbox. The spec says so.:
I think it's useful to know that "mailto:" means
someone is talking about a mailbox. And "ftp:" means
someone talking about a file, and "http:" means
someone talking about a document.
<Ian> DC: I think it's a handy heuristic that mailto:
refers to mailboxes, but not critical to arch of Web.
<TimBL> "HOLD THAT THOUGHT"
2.5 Postponed
1. Internet Media Type registration, consistency of
use.
+ Action PC 2002/07/08: Propose alternative
wording for finding regarding IANA
registration. Refer to "How to Register a
Media Type with IANA (for the IETF tree)"
2. uriMediaType-9: Status of negotiation with IETF?
See message from DanC.
+ Action TBL: Get a reply from the IETF on the
TAG finding.
3. RFC3023Charset-21:
+ Action CL: Send copy of information sent to
tag regarding RFC3023Charset-21 to www-tag.
4. 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.
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. RFC3023Charset-21
+ ACTION CL 2002/6/03: Send writeup on this
issue to www-tag.
7. 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.
2.6 New issues?
1. Bad practice: Overriding HTTP content-type with a
URI reference. See email from TBL.
2. "Deep linking illegal" bad practice? See email
from Tim Bray.
________________________________________________
Ian Jacobs, for TimBL
Last modified: $Date: 2002/07/16 02:43:23 $
Received on Monday, 15 July 2002 22:45:45 UTC