[Minutes] 8 July TAG teleconf (arch doc, media types, formatting props, whenToUseGet-7, augmentedInfoset-22)

Hello,

Minutes [1] available as HTML and text below.

  - Ian

[1] http://www.w3.org/2002/07/08-tag-summary
-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447


    W3C | TAG | Previous: 1 Jul | Next: 15 July | IRC log

           Minutes of 8 July 2002 TAG teleconference

    Nearby: issues list · www-tag archive

1. Administrative

     1. Roll call. TB, SW (Chair), DC, NW, IJ, CL, DO,
        PC. Regrets: TBL, RF
     2. Accepted this agenda.
     3. Next meeting: 15 July. Regrets: CL
     4. Accepted 1 July minutes
     5. Accepted summary of TAG activity in June
     6. Confirmed status of completed actions
     7. Quorum rules
     8. Prioritization of issues

   1.2 Completed actions

     1. Action IJ: Publish architecture document, asking
        in particular for input on issue httpRange-14.
        Done.
     2. Action SW: Respond to XMLP WG on behalf of TAG.
        Done.
     3. Action IJ: Integrate/combine one-page summaries
        (into architecture document)

   1.3 Quorum rules for the TAG

    The TAG charter does not include quorum requirements.
    The TAG agreed at this meeting not to institute
    quorum requirements, to use common sense when making
    decisions when few people are at a meeting.

   1.4 Prioritzation of issues

    The TAG began to discuss prioritization of its
    issues, when the topic shifted to expectations of a
    timeline for publishing the draft Architecture
    Document as a W3C Working Draft. There was general
    agreement that the TAG should do this as soon as
    possible (and certainly before resolving all the
    issues on its issues list). The TAG set a goal of
    further fleshing out this document and publishing a
    first Working Draft by mid-August, with a drop-dead
    date of 30 August.

    Action IJ: Find out whether the W3C Comm Team expects
    to have a publishing moratorium in August.

2. Technical

      * 2.1Architecture document
      * 2.2 Internet Media Type registration, consistency
        of use
      * 2.3 Consistency of formatting property names,
        values, and semantics
      * 2.4 Are we done with whenToUseGet-7?
      * 2.5 augmentedInfoset-22
      * 2.6 Postponed

    See also: findings.

   2.1 Architecture document

     1. ACTION TBL 2002/05/05: Negotiate more of IJ time
        for arch doc
     2. ACTION RF 2002/06/24: Write a paragraph on
        technical and political aspects of URIs and URI
        References.

    Review of some portions of the 1 July architecture
    document. The following notes have been reordered
    somewhat to map to arch doc sections.

     Section 1.1 URI schemes

    [Ian]

      TB: What do we do to make 1.1 work? Some of
      the things in the list under schemes are
      duplicates. Bullet one would apply to all URIs
      if we took RF's wording. Are other people
      happy with 1.1?
      DC: I think the list is interesting, but I'm
      not satisfied that it works.
      SW: I'd like to mention 1.1 scheme-agnostic.
      What about a table of schemes and properties?
      Section 1.1.1 is about persistence, also a
      property in the table. Should we have prose
      for each of the properties we identified?
      IJ: I think scheme properties are a useful
      entry point for other issues we encounter
      later on.

    Parallel actions TB, DC: Propose text for section
           1.1.

     Section 1.1.2 Central registries

    [Ian]

     CL: I have a problem with 1.1.2 (central
     registries). Centralized registries of
     formatting properties is also useful. As is
     the W3C /TR page.
     DC: /TR is not a centralized registry. It's
     not necessary for every party who does Web
     business to consult /TR to continue in life.
     /TR is not central to the operation of the
     Web.
     CL: So what about browsers making up HTML?
     TB: There's a qualitative difference between
     DNS and /TR.
     DC: There is a central registry for MIME
     types.
     CL: You don't have to look up IANA registry
     each time as a user.
     TB: But browser developer needs to have
     hard-coded.
     CL: Is the definition "You looked up once in
     one place" or "You have to look up each time."
     Having single points of failure is something
     else.

     DC: As written, the text doesn't make the case
     why central registries are bad. There are at
     least two: URI schemes, list of MIME types. I
     would still claim these are exceptions.
     CL: Is 1.1.2 for the whole document or just
     1.1?
     DC: I think in context. We like anyone to be
     able to make up names. But there are
     exceptions (e.g., DNS).
     CL: Then we should say that 1.1.2 only applies
     to naming.
     DC: But naming is the only place where central
     registries would come up.
     CL: Why is 1.4 part of section 1, not formats?
     SW: Part of a URI reference.
     DC: Good point, though. Maybe it could move to
     2 (with link to it from chapter 1)
     TB: On central registries - I think we are
     telling spec writers "Don't assume a central
     registry at W3C must be required in order for
     your spec to work." Given that principle, DNS
     is arguably unfortunate, but we're stuck with
     it. I think DNS different from getting a MIME
     type definition (since everyone does this all
     the time). I think that the intent of 1.1.2 is
     fine. I support the principle as stated and I
     think it applies to issues outside of URIs.
     Applies to protocols and formats as well.

   Section 1.1.1 Social expectations for URI persistence

     SW: Just before 1.1.2, we do some URN-bashing.
     What should we say about IETF efforts to make
     URNs dereferenceable?

     DC: This came up under Media type rubrique. I
     hope this is still on todo list. Michael
     Mealing has made points about IETF decisions
     regarding single points of failure. I was not
     aware of that decision. I would like to track
     down how decisions are made in that area. Two
     points

    1. TBL was out of line saying on the list that
       URNs are not dereferenceable.
       TB: But in fact URNs are *not*
       dereferenceable.
    2. Michael and Tim Bray seem to agree (on the
       list) to the fact that we should use
       dereferenceable URIs, whatever scheme.

     TB: I think we agreed that dereferenceability
     is a useful characteristic and that it's a
     good thing to call that out.
     DC: My issue with URNs is that they just
     recreate HTTP. HTTP has administrative
     hierarchy, and you get to do whatever you want
     in your HTTP space. As far as I can tell, URN
     technology doesn't change that - login, then
     search, then one TCP transaction. There should
     be an arch principle on not reinventing the
     wheel. Process question - how can TAG and IETF
     parties communicate better?
     TB: Principle - Persistence is a matter of
     policy, not technology. Nothing in HTTP
     prevents you from managing your space well.
     Perhaps we should just drop URN reference
     unless we take up DC's point that harmful to
     reinvent wheel.
     NW: I think we'd be hard pressed to argue that
     URN is a new scheme.
     TB: Please add a boxed principle: "Persistence
     is a key characteristice in URI design."
     DC: A comment I made on the phone with IJ - a
     lot comes down to "economics". Value to having
     name agreed by people. If it changes, then the
     value goes down.
     TB: We say "there are strong social
     expectations..."
     DC: The document doesn't say what the
     expectations are.

     DC: Two decisions were made in the IETF
     pertaining to URNs:

    1. DDNS documents proposed standard; I tracked
       down
    2. Decision not to use HTTP URIs to name
       protocols. I don't know where that decision
       was made.

     Action DC: Ask Michael Mealing when IETF
     decided not to use HTTP URis to name
     protocols.

   Section 2: Formats

    [Ian]

     CL: Not sure what I would write in Section
     2... Section 2 is the big bleeding piece for
     me.
     TB: I think the meat is in section 2. All it
     needs is to invest time to wrap text around
     each issue. Seems mostly editorial. You could
     build short sections for 2, as done for
     current 1.4.1. I think we have consensus on
     format properties as well.
     CL: You can put a list of alternatives around
     issues as well.

    Action CL: Write up some text for section 2. Deadline
    30 July.

     Additional principles

    [Ian]

     DC: One principle I've heard about formats is
     to separate presentation from structure is an
     arch principle as well.

   2.2 Internet Media Type registration, consistency of use

     1. ACTION DC: research the bug in the svg diagram.
        Done.
        TB, CL: Remove. PC: Neutral.
        DC: I'm happy to do without TBL since Martin said
        I18N folks would do something with it if TAG
        doesn't.
     2. ACTION NW 2002/06/24: Produce PNG version of
        image as well. Done.

    Resolved: Remove diagram from finding.

    [TBray]

     The finding is not done due to issue
     RFC3023Charset-21.

    [Ian]

     Current text:
     "If so, the IETF registration forms MUST be
     part of the language specification, and SHOULD
     be part of the specification starting at
     Candidate Recommendation status (or Last Call
     if the Working Group plans to have sufficient
     implementation experience to bypass Candidate
     Recommendation). "
     DC: IETF area directors didn't say you had to
     have the mime type in registry before you
     could use it.

    [DaveO]

     hmm.. seeming less and less like an
     architectural principle and more like w3c
     process issue.

    [Ian]

     IJ: The text must be in spec, but isn't
     required to be registered.
     DC: Area directors said "Don't want to put in
     the registry until it goes to Rec." They
     prefer to just have internet draft published
     every 6 months. They would rather your type
     not be in registry but not in internet draft
     index.
     CL: What can we point to when people tell us
     we are doing it wrong?
     TB: I agree with DO's point that this is a
     process issue. Let's rewrite finding to say
     that registration process must proceed in
     parallel with w3c process, and documents must
     be readily available from w3c specs.
     DC: Water down more: Registration information
     is relevant and needs to be reviewed along
     with everything else in your spec.
     IJ: Please note current best practice as we
     understand it.
     TB: if we write a strong arch principle saying
     "You have to get this work done" then that is
     enough for the Director to stand on.
     PC: I think we need a cookbook for chairs on
     what to do.
     DO: I'd rather us spend more time on arch
     principles and our issues list.

    [TBray]

     Particularly given that the TAG has
     substantial consensus... it's irritating that
     we have to keep investing time on this. If we
     want a cookbook, how do we get it?

    [Ian]

     DC: I agree that this is process, but who do
     we hand this to?
     PC: Our finding should say "here lie
     alligators" if uncertain process.

    Action PC: Propose alternative wording for finding.

    Action CL: Send copy of information sent to tag
    regarding RFC3023 to www-tag.

   2.3 Consistency of formatting property names, values, and
   semantics

     NW: I see Håkon's reply only now (due to email
     problem).
     CL: CSS WG wanted previous good behavior
     mentioned in the finding.
     DC: HWL's message suggested a central regisry.
     Are we saying "no thanks" to that suggestion?
     TB: Our finding is correct. Hakon suggested
     writing down a process. I don't think this
     changes the finding.
     CL: In other words, we don't care how you get
     it right as long as you do?
     DC: Works for me.
     NW: I will make another stab that mentions
     good behavior and presumably we can call it
     done at that point.

   2.4 Are we done with whenToUseGet-7?

     ACTION DC 2002/06/10: Send note to WSA WG
     expressing concern about normative binding for
     GET. Done.

     SW: Are we done with issue whenToUseGet-7?
     DC: Not to my satisfaction. I haven't seen
     message to or reply from WSA WG.

     DO: In my court. I've had discussions with
     various people. I'm still working on what
     possibly we should try to say to them.
     Certainly dealing with SOAP 1.2 is an issue
     before WSDL. I think we should go to them with
     something more refined.

     TB: I think that the news is good, however,
     notably on WSDL front. It's now on their
     radar.: My understanding is that they will
     build machinery to handle it.

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

   2.5 augmentedInfoset-22

     1. 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.
     Done (email to Schema WG).

     DC: I don't think we should close until we've
     heard back from them.
     NW: Schema WG tried to consider DC message at
     meeting 2 weeks ago. I don't think it was
     clear what we were asking them.
     DC: They need to tell me how they are
     confused. Please mark as open Tim's action
     regarding communication with IETF about media
     type names as URIs (issue URIMediaType-9). See
     message from DanC.

   2.6 Postponed

     1. Qnames as identifiers
          1. Action NW 2002/06/24: Follow up on Rick
             Jelliffe comments/proposal.
     2. httpRange-14: Need to make progress here to
        advance in Arch Document.
     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.

     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/09 23:50:01 $

Received on Tuesday, 9 July 2002 20:10:22 UTC