W3C | TAG | Previous: 8 Jul | Next: 22 July | IRC log
Nearby: Teleconference details · issues list · www-tag archive
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.
RF: I touched on this on mailing list, but this para is 2nd
priority to the URI spec itself.
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.
<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.
<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.
<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.
<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:
<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.
<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.
<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> 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"
<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"