W3C home > Mailing lists > Public > public-tag-announce@w3.org > December 2003

[Minutes] 1 Dec 2003 TAG teleconf (Arch Doc walkthrough, action review)

From: Ian B. Jacobs <ij@w3.org>
Date: Tue, 02 Dec 2003 08:51:44 -0500
To: www-tag@w3.org
Message-Id: <1070373104.14221.8.camel@seabright>

Minutes of the TAG's 1 Dec teleconf are available as
HTML [1] and as text below.

 _ Ian

[1] http://www.w3.org/2003/12/01-tag-summary.html

                 Minutes of 1 December 2003 TAG teleconference

1. Administrative

    1. Roll call: DC (Chair), SW, TBL, CL, DO, PC, RF, TB, IJ. Regrets:
    2. Accepted the minutes of the [9]15-17 Nov ftf meeting
    3. Accepted the minutes of the [10]24 Nov teleconf
    4. Accepted this [11]agenda
    5. Next meeting: 4 Dec 2003 teleconf at 8am PT / 11am ET. Review
       issues to close before last call.
    6. Video meeting in Feb 2003:
         1. Action SW/PC 2003/11/10: Explore possibility of TAG videolink
            TAG distributed meeting in February.
    7. Tech Plenary
         1. Completed action SW 2003/11/15: Take to tech plenary
            committee the TAG's proposal..
            SW: I haven't received a response from the committee yet
            (since they have yet to meet).
    8. Negotiations with WGs for last call:
         1. SW/I18N done
         2. Schema/PC done. MSM has confirmed.
         3. SVG/CL done. CL has confirmed.
         4. HTML/IJ done
         5. Todo: Voice/SW, XML Core/NW, WSDL/DO

      [9] http://www.w3.org/2003/12/15-tag-summary.html
     [10] http://www.w3.org/2003/11/24-tag-summary.html
     [11] http://www.w3.org/2003/12/24-tag.html

2. Technical (75min)

    1. Review of Architecture Document writing assignments

  2.1 Review of Architecture Document writing assignments

   Comments on [12]28 Nov 2003 WD of the Arch Doc?

     [12] http://www.w3.org/2001/tag/2003/webarch-20031128/

   Recent action items:


         1. Withdrawn action IJ 2003/10/08: Starting from DO's diagram,
            create a diagram where the relationships and terms are linked
            back to the context where defined. Ensure that the
            relationships are in fact used in the narrative; any gaps
            identified? With DO, work on term relationship diagram.
         2. Completed action IJ 2003/11/15: Add a column to the TAG
            issues list about the version of the document in which we are
            expecting to address the issue.
         3. Completed action IJ 2003/11/15: Provide wording to replace
            text in 1.1.2 about relation between arch doc and findings
            (w.r.t. good practice notes).
         4. Completed action IJ 2003/11/15: Revise SVG story in
            discussion with TBL.
         5. Completed action IJ 2003/11/15: Incorporate TBL and DC text
            into 3.4.
         6. Completed action IJ 2003/11/15: Fix ref to 30 at end of
            section 4.2
         7. Completed action IJ 2003/11/15: Fix para after 1./2. bullets
            in 4.3 to make clear that language must prepare in advance
            (i.e., syntax) for this type of override.
         8. Completed action IJ 2003/11/15: Write caveat about
            integration formats like FO
         9. Action IJ 2003/11/15: Close issue 6 with TB proposed text.
            (Done) Inform reviewer. (Not done)
        10. Completed action IJ 2003/11/15: In 4.6.4, amend story to talk
            about the choice of extensibility model and namespace policy
            how that helps them meet their desired goals (easy changes,
            less cost). Tie namespace change more strongly to
            extensibility model with a cross reference.
        11. Completed action IJ 2003/11/15: In section 4.6.6, add refs to
            infoset and PSVI.
        12. Completed action IJ 2003/11/15: Ensure that pointed to from
            issues list.
        13. Completed action IJ 2003/11/15: Add new issue regarding
            derived resources.
        14. Completed action IJ 2003/11/15: Add new issue


         1. Completed action CL 2003/07/21: Discuss and propose improved
            wording of language regarding SVG spec in bulleted list in
            2.5.1. ([13]Done)
         2. Completed action CL 2003/11/15: Propose a sentence for 4.4
            about delivery context.
         3. Action CL 2003/11/15: Write text to reviewer about the
            resolution of errorHandling-20.

     [13] http://lists.w3.org/Archives/Member/tag/2003Nov/0052.html


         1. Completed action NW 2003/10/08: Revise QName finding. See
            [14]draft finding from NW.
         2. Completed Action NW 2003/11/15: Provide language on
            cost/benefit trade-off of extensibility.
         3. Completed Action NW/IJ 2003/11/15: Rewrite 4.6.2. Revise
            first GPN per TB text. Second one ok. Take language from
            finding to give more context.

     [14] http://www.w3.org/2001/tag/doc/qnameids-2003-11-03


         1. Completed action TB: Rewrite paragraph on ambiguity in
            section 2.2.


         1. Action RF 2003/10/08: Explain "identifies" in RFC 2396.
            RF: The current draft expires this week...I'd better do
            it...please continue.


         1. Completed Action DO/TBL 2003/11/15: Produce new text for a
            small subsection 1.2.4 (or perhaps for 1.2.1)
            [TBL not satisfied with how text incorporated; see below]
         2. Action DO 2003/11/15: Point WSDL WG to resolution of issue 6.
         3. Action DO 2003/11/15: Propose some extra text for section 4.5
            that hypertext agents often follow an IGNORE rule and this
            often results in incompatible behavior. Ignore applied to
            fragid interpretation.
            MOVE TO ISSUES LIST.


         1. Action TBL 2003/07/14: Suggest changes to section about
            extensibility related to "when to tunnel".
            MOVE TO ISSUES LIST.


         1. Withdrawn Action DC 2003/07/21: Propose language for section
            2.8.5 showing examples of freenet and other systems.
            Progress; see [15]URISchemes/freenet
         2. Completed action DC 2003/11/15: Elaborate on value of
            orthogonality of specs in section 1.2.1 including example
         3. Completed action DC 2003/11/15: Write up some replacement
            text for text at beginning of 3.3.1.
         4. Action DC 2003/11/15: Follow up on KeepPOSTRecords with Janet
            Daly on how to raise awareness of this point (which is in

     [15] http://esw.w3.org/topic/UriSchemes_2ffreenet


         1. Action SW 2003/11/15: Verify that "agent" is used
            consistently in the document and makes sense as both people
            and software. [Subsumed by IJ?]

                      TBray: Better than it used to be.
                      IJ: I agree with TB.
                      SW: Please continue my action 1.

         2. Completed action SW 2003/11/15: Provide photo of
            extensibility/versioning whiteboard notes for the meeting
            record ([16]Done)
            Action IJ: Link to SW's photos from 15 Nov ftf meeting

     [16] http://lists.w3.org/Archives/Member/tag/2003Nov/0074.html

  Walkthrough of Tim Bray review of 28 Nov draft

   [17]TB review comments

     [17] http://lists.w3.org/Archives/Public/www-tag/2003Nov/0076.html


          1.2.1. Orthogonal Specifications
          TBray: CL and I had some back and forth on this.

          and http-equiv="refresh now"

          TBray: I like the motherhood and apple pie language before the
          bulleted list.

          " The HTML specification allows content providers to instruct
          HTTP servers to build response headers from META element
          instances. This is a clear abstraction violation; the developer
          community deserves to be able to find all HTTP headers from the
          HTTP specification (including any associated extension
          registries and specification updates per IETF process).
          Furthermore, this design has led to confusion in user agent
          development. The HTML specification state

          TBray: I think the first sentence needs rephrasing. The HTML
          spec supplements HTTP servers.
          CL: In fact, the HTML spec is an instruction for HTTP servers,
          which is universally ignored. That's evidence of a problem
          having arisen.
          TBray: Perhaps a bit of phrasing "This doesn't work in deployed
          servers as specified!"

          3rd bullet: " Some authors use the META/http-equiv approach to
          declare the character encoding scheme of an HTML document. By
          design, this is a hint that an HTTP server should emit a
          corresponding "Content-Type" header field. In practice, the use
          of the hint in servers is not widely deployed and many user
          agents peek inside the HTML document in preference to the
          "Content-Type" header field. This works against the principle
          of authoritative representation m

          Action IJ: Salt this text to taste to emphasize that problems
          have arisen.

          emph " servers is not widely deployed "

          RF: There are servers that implement it, FYI. [Some] Content
          management systems do this.

          content magagement systems, and the discontinued GN server
          yes, i agree that a sentence of introduction would be helpful

          TBL: The gist is missing: It's not just enough to make an
          extension language, you also need to make it so that not only
          old documents members of the new language, but also that new
          docs, without much damage, can be interpreted in the old
          language. Ok that extension is inverse of subset. Missing text
          is that you need to ensure that a doc in the extension language
          can be interpreted in the old language with predictable

          "second" and "first" is ambiguous

          TBL: Should be in para about "Language extension".

          I note "we", the TAG decided on whatever timbl, daveo, and Ian
          agree to.

          TBL/DO's text came from:

     [18] http://www.w3.org/2001/tag/2003/webarch-20031111/tim

          "Clearly, an extension language is better than an incompatible
          language, but in practice greater compatability is needed.
          Ideally, an instance of the superset language, in many cases
          can be safely and usefully processed as though it were in the
          subset language. Extensability the property of a langauge that
          allows this. The original language design can accomplish
          extensability by defining, for predicable unknown extensions,
          the handling by implementations -- for

          Language A' is an extension of language A if and only if A is a
          subset of A'.

          TBray: I think CL and I agree that most of the issues are
          probably not controverial.
          CL: I agree with TB's assessment.

          my response at

     [19] http://lists.w3.org/Archives/Public/www-tag/2003Dec/0018.html

          1.2.4 Is the 2nd sentence of the first para, about the
          longevity of
          messages, new in this draft? It doesn't have anything to do,
          not in
          the slightest, with the actual point being made in this
          TBray: Propose to lose that sentence.
          CL: Fine to drop.
          Action IJ: s/messages exchanged/technology shared.

          "the technology shared among agents in the Web may last longer
          than the agents themselves" would also be fine.

          TBray: I propose that second para be dropped.
          First sentence only?
          TB proposal: Rewrite first sentence per CL proposal.

          So, I agree with Tim about loosing the last para, but also
          suggest deleting "not in terms of APIs or data structures or
          object models, but in terms of protocols,". Make a positive
          point about the benefits of message based interop, its not
          necessary to knock other approaches to make the point.
          ian does now

          s/content and sequence/content,sequence and semantics/

          deletion proposed *is* in IRC

          s/not in terms of APIs or data structures or object models,

          (in FIRST para)

          "The Web follows Internet tradition in that its important
          interfaces are defined in terms of protocols, by specifying the
          content and sequence of the messages interchanged."

          TBL: I'd like semantics to go in para.
          TBray: I can live with semantics.

          "The Web follows Internet tradition in that its important
          interfaces are defined in terms of protocols, by specifying the
          content, sequence and semantics of the messages interchanged."

          The Web follows Internet tradition in that its important
          interfaces are defined by specifying the content and sequence
          of the messages interchanged.

          The Web follows Internet tradition in that its important
          interfaces are defined in terms of protocols, by specifying the
          content, sequence, and semmantics of the messages

          s/content, sequence and/syntax, semantics, and sequence/

          The Web follows Internet tradition in that its important
          interfaces are defined by specifying the content, sequence and
          semantics of the messages interchanged.

          I'm OK with that


          CL: Fine.

          +1 to roy

          The Web follows Internet tradition in that its important
          interfaces are defined in terms of protocols, by specifying the
          syntax, semantics, and sequence.of the messages interchanged

          go for it

          Resolved: Accept TB's sentence.
          Proposed: Drop third para.
          Resolved: Drop third para.
          TBray: 2. Would anyone else like to tighten up the first para
          by retaining just the first and last sentences? It would be
          immensely clearer I think.

          Parties who wish to communicate must agree upon a shared set of
          identifiers and on their meanings. Thus, Uniform Resource
          Identifiers ([URI], currently being revised) which are global
          identifiers in the context of the Web, are central to Web

          CL: I'm ok with losing second sentence...

          /me diff's are so much clearer

          I am fine with Tim Brays text

          I note that this value bit comes back later in the section on
          DC: I meant "network effect" sentence as motivation for first

          Ian, you wanted to talk about https if we get there. and to

          IJ: There's a tie-in in 2.3 in section on ambiguity.
          DC: I don't like first para of 2.
          CL: +1 to TB's proposal.
          TBL: Delete 2nd sentence, leave third.


          Resolved: Delete sentence two of first para of 2.
          TBray: I don't understand "Of particular importance are those
          messages that express a relationship between a URI and a
          representation of the resource it identifies. "
          DC: Those are "200 Ok" responses.
          TBray: Then please send that.
          IJ Proposal: Clarify intent of sentence in question as last
          sentence of para of 2.2.

          seems redundant to the sentence following it

          DC: The point is that the way URIs take on meaning is that you
          get representations back when you deref the URI; 200 Ok
          reponses are thus key.

          yes, but doing well I think, have covered most of my hot-button

          DC: I'm ok to lose the sentence, having heard RF.
          Proposal to delete "Of particular importance are those messages
          that express a relationship between a URI and a representation
          of the resource it identifies."


          CL: ok
          DC: Ok
          TBray: Ok
          TBL: Ok


          Resolved: Delete said sentence of 2.2.
          s/URI ownership URI/URI ownership
          [Editor notes]
          3.2. Messages and Representations
          TBray: I propose change to read: "A messsage may include: data,
          metadata about the data, and metadata about the resource."

          Some is about the resource, some is specific to a particular
          resource representation.

          CL: My point was that some is about the resource, some about
          the representation.: E.g,. content-language is about the
          TBray: Change to "metadata about the representation data"

          we need to say both - resouece and representation metadata
          'Vary' for example is about the resource

          TBL: Simplify to metadata about the resource and the message.

          may include data and metadata about the resource and the

          by "general" do you mean "typical"?

          IJ: I moved "resource metadata" out of ordered list since not
          the general case.

          message ~= message metadata, representation, represenation
          metadata and resource metadata?

          may include representation data as well as metadata about the
          resource, the representation, and the message.

          Propose: A message may include data, and metadata about the
          resource and the message.

          +1 to TBray's draft

          CL, DC: We prefer TB's proposal.

          prefer tbrays one

          prefers TBray's draft

          A message may...


          Resolved to accept TB"s proposal.
          TB Proposal: Lose GPN just before 3.5

          Lose GP at end of 3.4.1

          TBray: We say the same thing in preceding para (as in GPN)

          "Server managers MUST ensure that resource metadata is
          appropriate for each representation."

          This is not the responsibility of server managers.

          s/appropraite for each represnetation/correct

          how about s/approriate/accurate/


          s/each/all the/

          CL: My point is that if your metadata says something about a
          resource, make sure it works for all representations.
          RF: I don't think this is appropriate at all. It's not the
          server manager's responsibility. A server manager is incapable
          of knowing all the resources in the server namespace. The
          metadata depends on how the author intends a resource to be
          used (through representations).

          timbl, you wanted to point out that we can't really go into the
          disnction between different parties in the publisher.

          TBL: I think that RF's distinction is between different parties
          within the publisher (abstraction).
          IJ proposal to either add "metadata, especially that applying
          across representations" and deleting GPN.

          +1 to what Ian said
          ok now to drop the box

          Chris, you wanted to argue that distinguishing between resouce
          and representation is the crucial thing; drop 'server manager'

          Proposed rewrite of sentence before GPN: Furthermore, server
          managers can help reduce the risk of error through careful
          assignment of representation metadata (especially that which
          applies across representations)." And delete GPN.

          so RESOLVED.

          3.5 Why the new XForms plug? It adds nothing to the example and
          creates confusion because people are going to wonder if this is
          special and different and couldn't have been done with
          old-fashioned HTML forms. Must be removed.

          suggestion: Resource owners must manage the resource's provided
          metadata as carefully as they manage the data, ensuring that
          they remain consistent with the intended semantics of the

          TBray: Move back from Xforms to HTML forms. Might make people
          think that you need Xforms to do this.
          CL: Propose "for example" around Xforms.
          TBray: I'm fine with that.

          add "for example' right before xforms


          Proposed: "Built with, for example, XForms")
          RF: I think the idea is good, not sure it improves readability.

          (built with XForms ro HTMl forms)

          OK with TBL's too

          simple is better

          TBray: Propose to lose parenthetical

          Could we see the text we agreed on at the f2f in the 111?

          DC: +1 to lose parenthetical
          RF: +1 to lose parenthetical
          Resolved: Lose parenthetical re: xforms.

          Chris, you wanted to say it makes a link to a finding

          DC: Finding is cited in last para of the section.
          4.2.2 "must understand". I totally don't agree that "must
          understand" is limited to markup from another namespace. XHTML
          could for example have applied a "must understand" policy to
          new XHTML elements (they may have, for all I know). All you
          need to do is /markup from an unrecognized
          namespace/unrecognized markup/
          DO: That's correct.
          CL: Namespace can be relevant.:You could have different
          handling whether in or out of namespace (and unrecognized).


     [20] http://lists.w3.org/Archives/Public/www-tag/2003Nov/0074.html

          TBray: CL's example is deceiving. It's a particular example,
          less simple.
          DO: +1 to TB
          TBL: +1 to TB.
          Resolved to accept TB's proposal.
          4.3 The para beginning "Note that when content, presentation,
          and interaction are separated" is *very* fuzzy and I think
          could just be nuked. I don't remember discussing this, is it
          the output of TAG discussion?

          TBray proposes to delete para "Note that when content,
          presentation, and interaction ..."
          CL drafted it, Ian rewrote it

          TBray: I withdraw my comment.
          4.5.2 is the TAG comfy with being this much in favor of
          XPointer? I'd need to hear a few explicit "YESes"

          To define fragment identifier syntax, use at least the XPointer
          Framework and XPointer element() Schemes.

          TBL's text was this: "XLink is an appropriate specification for
          representing links in hypertext XML applications." (4.5.2)

          Please condense all four paragraphs of 4.5.2 into one.

          +1 to Roy

          TBL proposal: Move "XLink is an appropriate specification for
          representing links in hypertext XML applications." to 4.4

          I think that 4.5.2 is fine as it is

          Support for move: TB
          TB, CL: Leave where it is.

          better where is is

          TBL: Proposed change title of section to 4.5.2to "Hyperlinks in

          Propose moving "XLink is an appropriate specification for
          representing links in hypertext XML applications." to before "
          XLink allows links to have multiple ends"

          Middle of 1st para of 4.5.2

          TBL: I think that makes sense..........

          establishes a hypertext context

          IJ proposes louder back link to hypertext section

          editorial: s/( in | for ) XML// for all section headings 4.5.*

          IJ summarizing proposed changes to section 4.5.2:

         1. s/use at least/consider
         2. move third para to first para per CL proposal.
         3. Link back to hypertext links section.

          +1 to Roy

          TBray: +1
          TBL: +1
          SW: Don't use "consider" twice in same para.

          yes we do


          "specifically" might help, yes.

          Resolved: Accept IJ proposal.
          4.5.5 2nd para, 2nd sentence is COMPLETELY WRONG. Yes, you can
          convert back & forth between qunames & URI/local-part pairs.
          What you can't do is go back & forth from qnames to URIs; which
          is clearly what Norm meant.
          TBray: Yes there is. What there isn't is qname -> URI.

          There is no single, accepted way to convert a QName into a URI
          or vice-versa.

          There is no single, accepted way to convert a QName into a URI.

          don't lose vice-versa please
          OK chris?

          SW, TBL: Qualified names and QNames are different.

          First sentence defines them as same.

          TBray: I think SW is right.

          Propose s/("Qnames")//

          section is called "4.5.5. QNames in XML" so no ambiguity...

          IJ: I am confused seeing qualified name , then qname, then not
          understanding the relation.
          TBray: Nuke "QName", then insert a sentence explaining

          /me I need to go, but please continue without me

          TBL: "Qualified names were introduced by XMLNS and are
          represented in XML by the "Qname" construct."

          thanks, roy

          IJ: I understand the proposed change the goal of ensuring that
          text is not inconsistent.

          PROPOSED: to fix QName stuff to the satisfaction Lilley and

          TBray: +1

          so RESOLVED.

          Action IJ: Do another draft by Thursday, 4 Dec..


   The TAG does not expect to cover these issues

  2.2 Review of 3023-related actions

    1. Action CL 2003/10/27: Draft XML mime type thingy with Murata-san

  2.5 Findings

   See also [21]TAG findings home page.
     * [22]whenToUseGet-7: Finding: [23]URIs, Addressability, and the use
       of HTTP GET and POST
     * [24]contentPresentation-26: Draft finding: [25]Separation of
       semantic and presentational markup, to the extent possible, is
       architecturally sound
     * [26]contentTypeOverride-24: 9 July 2003 draft of [27]Client
       handling of MIME headers
         1. Completed action RF 2003/09/15: Proposed substitute text in
            light of [28]previous comments on charset param. ([29]Done)
         2. [30]Comments from Philipp Hoschka about usability issues when
            user involved in error correction. Is there a new Voice spec
            out we can point to for example behavior?
         3. [31]Comments from Chris Lilley
         4. Lots of [32]comments from Martin Duerst
     * [33]metadataInURI-31

     [21] http://www.w3.org/2001/tag/findings/
     [22] http://www.w3.org/2001/tag/issues.html#whenToUseGet-7
     [23] http://www.w3.org/2001/tag/doc/whenToUseGet-20030922
     [24] http://www.w3.org/2001/tag/open-summary.html#contentPresentation-26
     [25] http://www.w3.org/2001/tag/doc/contentPresentation-26-20030630.html
     [26] http://www.w3.org/2001/tag/open-summary.html#contentTypeOverride-24
     [27] http://www.w3.org/2001/tag/doc/mime-respect.html
     [28] http://lists.w3.org/Archives/Public/www-tag/2003Jul/0051.html
     [29] http://lists.w3.org/Archives/Public/www-tag/2003Sep/0043.html
     [30] http://lists.w3.org/Archives/Member/tag/2003Jul/0076.html
     [31] http://lists.w3.org/Archives/Public/www-tag/2003Jul/0113.html
     [32] http://lists.w3.org/Archives/Public/www-tag/2003Sep/0108.html
     [33] http://www.w3.org/2001/tag/open-summary.html#metadataInURI-31

    2.2.1 Expected new findings

     * [34]siteData-36
     * [35]abstractComponentRefs-37
       Completed action IJ 2003/11/03: Publish DO's latest draft in
       finding format ([36]Done)

     [34] http://www.w3.org/2001/tag/issues.html#siteData-36
     [35] http://www.w3.org/2001/tag/issues.html#abstractComponentRefs-37
     [36] http://lists.w3.org/Archives/Public/www-tag/2003Nov/0008.html


    Ian Jacobs for Stuart Williams and TimBL
    Last modified: $Date: 2003/12/02 13:41:48 $

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

Received on Tuesday, 2 December 2003 08:54:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:44:27 UTC