W3C home > Mailing lists > Public > www-tag@w3.org > July 2002

[Minutes] 15 July TAG teleconf (arch doc, qnames as ids, formatting props, httpRange-14)

From: Ian B. Jacobs <ij@w3.org>
Date: Mon, 15 Jul 2002 22:42:38 -0400
Message-ID: <3D33881E.1050506@w3.org>
To: www-tag@w3.org


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

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
        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
        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
     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

    <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

    <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

    <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"?

    <Ian> TBL: Column heads: Persistence and

    <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

    <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

    <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

    <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

    <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

    <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,

     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

    <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

    <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

    Action NW: Revise and publish Qnames as identifiers

   2.3 Consistency of formatting property names, values, and

    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

    <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

    <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

    <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

    <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.


   2.5 Postponed

     1. Internet Media Type registration, consistency of
           + 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:52 UTC