[Minutes] 14 Jul 2003 TAG teleconf (WS visibility, Extensibility, Arch Doc, Charmod conformance)


Minutes of the 14 July 2003 TAG teleconf are available
as HTML [1] and as text below.

 - Ian

[1] http://www.w3.org/2003/07/14-tag-summary


                  Minutes of 14 July 2003 TAG teleconference

1. Administrative

    1. Roll call: SW (Chair), TBL, TB, DO (for first hour), DC, RF, CL,
       PC, IJ (Scribe). Regrets: NW.
    2. Accepted corrected minutes of [8]30 Jun teleconference
    3. Accepted minutes of [9]7 Jul teleconference
    4. Accepted this [10]agenda, but rearranged order of items.
    5. Accepted [11]draft summary of TAG activity
    6. Next meeting: 21-23 July ftf meeting

      [8] http://www.w3.org/2003/06/30-tag-summary.html
      [9] http://www.w3.org/2003/07/07-tag-summary.html
     [10] http://www.w3.org/2003/07/14-tag.html
     [11] http://lists.w3.org/Archives/Member/tag/2003Jul/0036.html

  1.1 Face-to-face meeting agenda

   The TAG reviewed a [12]draft agenda.

     [12] http://www.w3.org/2001/tag/2003/07/21-tag


          SW: (1) namespace doc (2) LC pub. [pls put those meeting goals
          atop [13]http://www.w3.org/2001/tag/2003/07/21-tag ]

     [13] http://www.w3.org/2001/tag/2003/07/21-tag

          SW: Two meeting goals (1) Arch doc decision (2) RDDL and
          DC: I recommend incorporating reading list in the agenda.
          TBL: Is the question of resolving httpRange-14 before last call
          on the agenda?
          SW: I think that we've discussed this and decided httpRange-14
          should neither be on the agenda nor a block to last call.
          TBL: I'll try to work with RF during the breaks [on

2. Technical

    1. New issue? [14]Viability of Web Services
    2. [15]Text from David Orchard on Extensibility for Arch Doc
    3. [16]Architecture Document
    4. New issue? [17]Character model conformance

  2.1 New issue? Viability of Web Services

          DO: WSA WG has been talking about different arch styles and
          looking at properties achieved by application of various
          constraints. There is a section of the 14 May draft of the
          document that includes text about the property of "visibility"
          that Mark Baker disagrees with. In particular, in non-REST
          systems that are using XML, visibility comes from the fact that
          the content is in XML. In a multi-protocol environment (with
          open and proprietary protocols), the assertion is that using
          XML-based queries to poke inside gives a certain level of
          visibility into what the message is doing. Mark is states that
          there is too much visibility (compared to REST interfaces). The
          WSA is asserting that in multi-protocol environments, there are
          technologies for peeking into the XML structure. Mark asserts
          that the fact that you have to look inside means inferior
          TBray: I think there is no issue here. I think that MB subtext
          is that if you have a small set of verbs, this would provide a
          better mechanism for "visibility". I think that's probably
          wrong. Intermediaries will peek inside; pretending that that
          won't happen is silly. The term "visibility" is poorly defined.
          And pretending that there's another way to do this than peeking
          inside is [missed]
          [DO seeks to clarify MB's point of view.]

          timbl__, you wanted to ask for a clarification of what Mark
          means by "restful web services", maybe with an example?

          DO: Well-defined constrainted interface makes configuration
          simpler. Well-defined set of verbs improves performance. I
          think that "visibility" is a combination of those two concepts.
          An example: say you are doing GET of a stock price - you look
          inside the URI and the HTTP verb and the intermediary can make
          a decision. If you look inside a POST.... Two important things
          here: (1) Visibility is harder when there is more than one

          no, its not harder. its a question of tunelling or not, and
          protocol independence or not

          DO: Idea is to use xpath expressions to look inside xml
          content. HTTP as an application protocol does an excellent job
          for doing things like visibility. But people want to use otherp
          rotocols, too. Idea is to use xpath queries for any protocol.:
          Mark doesn't address case of deployment of application across
          multiple protocols.

          There's a fantasy here that firewall will loook at the message
          and say "it's a PUT and xyz is allowed to put, so I'll pass it
          through without looking at the XML message body." I don't buy

          TBL: What MB's point about using HTTP GET, or does he say you
          can use POST in a RESTful way?

          over in son-of-RSS-land, we're converging on using POST for
          entry creation/update/deletion for reasons that seem good

          Visibility is a variable property (like most properties).
          Things that are universal standards are inherently more
          "visible" than object-specific semantics, because you don't
          have to go look up the non-standard semantics. It is a design
          trade-off. There is no point in convincing Web Services to use
          a uniform interface, since the whole point of WSA is to develop
          programmable interfaces.

          DC: I don't know what "visibility means If this is only an
          issue of GET v. POST, that's issue get7.
          RF: "Visibility" is what it sounds like - you can tell more
          about the message/interaction in some cases.: I don't think
          this is a TAG issue. If you have a programmable interface, it's
          by definition not the generic interface.: Visibility is not
          absolute; it's variable.

          Chris, you wanted to ask if this is not inherrent in any xml

          RF: It's also true that an HTML form composition dialog is a
          very visible component, so it's easy for users to anticipate
          params by inspection.

          I do no think we have understood the issue.

          TBray: I suggest we write a note that says that Web services
          are inherently less visible than HTTP, this is why they are
          being worked on, we don't see an issue.
          CL: To me, this is an issue of whether Web Services are opaque
          tunneling, or whether they add something
          DO: I think that the point that needs to be made is that, in
          HTTP, GET/PUT/DELETE are not the end-all of communication. And
          other protocols are in use. So if you want to deploy an
          application across multiple protocols, I don't know whether you
          do have "better visibility" with core HTTP. You'll have to peek
          inside message bodies anyway. You'll want to standardize

          if its opaque tunnelling, then peeking is bad


          SW: Does anyone want to take this up?
          - Thank Mark
          - Say that the TAG doesn't feel this is an issue we want to
          take up.

          if it adding 'xml headers' then its not peeking, its part of
          the (extended) protocol

          DanC, you wanted to ask to move on; we don't need to decide
          anything. let the record show a lack of support for adding the
          issue to the issues list and that's it.

          DO: Should we say that the TAG supports what the WSA WG is
          TB, RF: No.

   The TAG did not accept a new issue on this topic.

  2.2 Text from David Orchard on Extensibility for Arch Doc

   [18]Text sent by David Orchard about extensibility

     [18] http://lists.w3.org/Archives/Public/www-tag/2003Jun/0086.html

          DO: Text is on versioning, how versioning relates to
          extensibility, backward and forward compatibility Also,
          handling unknown content. Also, mandatory extensions. I
          received some comments about the last part on determinism.
          CL: The text seems good.

          +1 for citing PNG spec. more precedents are good

          CL: The PNG spec could also be cited as an example of a spec
          that includes forward/backward compatibility pieces.: Text
          seems good and clear.
          IJ: CSS also has for/back compatibility features.
          TBray: I agree that first part is useful. However, I think that
          determinism section is (a) not architectural and (b) a design
          error in schemas and dtds. Relax NG shows this can be done.

          "should provide such a facility" --> "should be

          DO: I can live with dropping that section. Argument that I will
          continue to make in favor of keeping is that the "bad choice"
          for dtds and schemas should be cited as bad practice.
          DC: No, don't talk about determinism. I don't see this as
          architectural. Might be interesting to visit in a finding, but
          not in arch doc.
          TBray: I think it's useful to publish something somewhere about
          good practice, but not in arch doc.
          TBL: "When to tunnel" is an interesting question. I think that
          it's good to put the text that DO proposed. There seems to be a
          confusion between document and document type in a few places.
          Distinguish modified doc instances (tunneling) and layering...

          timbl_, you wanted to pull out the extension by enveloping

          DO to TBL: Some interesting comments; please suggest text.
          Action TBL: Send suggested changes to text proposed by David.
          Resolved: IJ to incorporate DO's email minus section on
          determinism in Editor's Draft of Arch Doc.: IJ to incorporate
          DO's email minus section on determinism in Editor's Draft of
          Arch Doc. Comments from TBL and others welcome.

  2.3 Architecture Document

   [19]27 June 2003 Working Draft of Arch Doc

     [19] http://www.w3.org/TR/2003/WD-webarch-20030627/

          DC: I don't expect to read a full new draft between now and the

          +1 for most-polished version

          IJ: I can have a new draft tomorrow.
          Action IJ: Publish Editor's draft 15 July.

          +2 for draft I can read on flight back to USA Thursday

          TBray: I'll commit to having looked at it by Monday

          I'm happy for editor to polish all he likes, as long as I'm not
          expected to have it read before the meeting

   Review of other action items associated with the Architecture

   [20]27 June 2003 Working Draft of Arch Doc published.
    1. Action RF 2003/06/02: Rewrite section 5. Section 5 is expected to
       be short.
    2. Action IJ 2003/06/16: Attempt to incorporate relevant bits of
       "[21]Conversations and State" into section to be produced by RF.
    3. Action SW 2003/07/07: Try to get TimBL to sign off on Paul's text.
       If SW able to reach TBL, SW/TBL send to AC as co-chairs. If not,
       have IJ send on behalf of TAG.

     [20] http://www.w3.org/TR/2003/WD-webarch-20030627/
     [21] http://www.w3.org/DesignIssues/Conversations

          no progress on my arch doc action item: Action RF 2003/06/02:
          Rewrite section 5. Section 5 is expected to be short.

          Action SW 2003/07/07: Try to get TimBL to sign off on
          [22]Paul's text. If SW able to reach TBL, SW/TBL send to AC as
          co-chairs. If not, have IJ send on behalf of TAG.
          TBL: I will look at this offline with SW (and IJ if necessary).
          PC: Please do this asap. Preferably we want feedback from the
          AC before our ftf meeting.
          TBray: I suggest this be sent by end of day...
          TBL: I think discussion was more about "not covering" than
          DC: There's some data suggesting that the AC wanted "complete
          doc later" and we are doing "incomplete doc now". I agree that
          should be sent today.
          Action TBL (with IJ support if necessary): Send email about TAG
          expectations re: arch doc to last call today.

     [22] http://lists.w3.org/Archives/Member/tag/2003Jul/0019.html

  2.4 New issue? Character model conformance

   [23]Issue raised by TBL.

     [23] http://lists.w3.org/Archives/Public/www-tag/2003Jun/0009.html

          CL: Our charter says we may point to architectural recs
          elsewhere rather than define.
          TBL: Issue is the distinction between policy and architectural
          statement. There was a suggestion that the TAG make the policy
          point and leave the arch issue in the char mod specification.
          CL: I would support the arch doc making the policy point.

          DanC, you wanted to ask about how WGs discover this charmod bit

          DC: To me this comes down to communication/enforcement. We have
          tried to keep the arch doc brief (so more people will read it).
          We talked about char mod spec being split into three. As far as
          I know, they have not done it.

          also, putting it in arch doc means it applies to everyone, not
          just 'w3c wgs'

          DC: I don't expect everyone to read the entire (three parts) of
          charmod together. I support taking this up as an isuse.

          +1 to taking up this issue

          PC: Does this mean that our charter is wrong if we are only
          group with enforcement power...
          CL: I think this is not merely procedural. I think that they
          don't really mean "Just W3C groups". I think they mean
          "Everyone should use this." They happened to use procedural
          methods to try to express this.

          timbl_, you wanted to say no, our charter is not wrong. Two
          things. (1) No one not even the TAG says "every one in W3C must
          do this and (2) ...

          TBL: Arch work is done in lots of places. The TAG says "It's
          architecturally sound/unsound to do..." We don't limit
          ourselves to W3C WGs. Various entities could make this
          statement. Reasons why the TAG should do this - a lot of the
          spec is technical (e.g., on canonicalization). The community
          has asked for "one place" to look. A two-liner would help the
          community, and the place for that is the arch doc.
          CL: We should reiterate to I18N WG that we would like them to
          split their spec in 3.

          based on different maturity levels of different sections.

          TBL: "Is is architecturally unsound to design systems that do
          not use the W3C Character Model?"
          CL: Needs to be crisper than that. E.g., granularity of changes
          and relation to requirement for normalization (e.g., after each
          modification in the DOM? Sum of modifications?)
          TBL suggests title of issue: "What arch issues are raised by
          the char mod spec?"
          TBray: I would support TBL's first expression of the issue. I
          wouldn't support investing more time in this issue until char
          mod has been split up.
          Straw poll: Should the TAG accept this issue?

         1. Yes: CL, DC
         2. Abstain: TB, RF, SW
         3. No: PC

          Punt on this until the I18N WG finishes the specification.

          TBL: Should we send a review that says until split we won't
          take this up.


     [24] http://www.w3.org/2001/tag/ilist#charmodReview-17

          See [25]comments sent by CL that the TAG expects to be handled.
          TBray: Proposed (1) No consensus to take up (2) Discomfort on
          status of charmod draft.

     [25] http://lists.w3.org/Archives/Public/www-tag/2002May/att-0164/charmod-notes.txt
     [26] http://lists.w3.org/Archives/Public/www-tag/2002Jun/0020.html

          *portions* of it are very uncooked, and they have not responded
          to our change requests.

          TBL: Can we tell that that if they have a charmod doc,
          procedurally we would have no problem pointing to them?
          CL: I would argue for the first part (normalization). Other
          parts would require CR first.
          DC: Please move 17 to pending, not resolved.
          Action IJ: Move issue 17 to pending rather than resolved.
          Action DC: Remind I18N WG of what we are expecting regarding
          issue 17; send this on behalf of the TAG.

          SW: TAG does not take up new issue regarding char mod.

3. Not discussed at this meeting

  3.1 Findings

   See also: [27]findings.

     [27] http://www.w3.org/2001/tag/findings

   Next steps on these findings:
     * [28]contentTypeOverride-24: 9 July 2003 draft of [29]Client
       handling of MIME headers
         1. Completed action CL, NW 2003/06/30: Read the draft finding by
            7 July. [30]NW Done, [31]CL Done
         2. Completed action IJ 2003/07/07: Produce a new draft of the
            finding on MIME headers that takes into account comments from
            Rob Lanphier, TBL, NW, SW (editorial), and above resolution.
         3. Completed action IJ 2003/07/07: Follow up with SYMM IG saying
            we'll take into account input and produce new draft of this
         4. [32]Comments from Roy on charset param
         5. [33]Comments from Chris Lilley
     * 9 July 2003 draft of [34]URIs, Addressability, and the use of HTTP
       GET and POST
          + [35]whenToUseGet-7
               o Completed action IJ 2003/06/23: Incorporate a sentence
                 about scope based on LM comments.
               o Completed action IJ 2003/07/07: Produce new draft of
                 finding with (1) change based on LM comment, (2) text
                 from DO/NM (3) don't address PUT in this finding, but
                 add comment about new issue [36]putMediaType-38 (second
                 point in [37]summary of comments).
               o Subsumed action DO 2003/07/07: Send text that DO and
                 Noah M. can agree to to tag@w3.org. (DO should verify 9
                 July text)
     * [38]metadataInURI-31: 8 July 2003 draft of "[39]The use of
       Metadata in URIs"
          + Completed action SW 2003/07/07: Create new draft based on
            input today and send to www-tag.
          + Action DO 2003/07/07: Send rationale about why WSDL WG wants
            to peek inside the URI.
          + See also [40]TB email on Apple Music Store and use of URI
            schemes instead of headers
     * [41]xmlIDSemantics-32:
         1. [42]Chris Lilley draft finding.
         2. Action CL 2003/06/30: Revise this draft finding with new
            input from reviewers. 7 July Deadline.
     * [43]contentPresentation-26: Action CL 2003/06/02: Make available a
       draft finding on content/presentation.
     * Action IJ 2003/06/09: Turn [44]TB apple story into a finding.

     [28] http://www.w3.org/2001/tag/open-summary.html#contentTypeOverride-24
     [29] http://www.w3.org/2001/tag/doc/mime-respect.html
     [30] http://lists.w3.org/Archives/Public/www-tag/2003Jul/0028.html
     [31] http://lists.w3.org/Archives/Member/tag/2003Jul/0049.html
     [32] http://lists.w3.org/Archives/Public/www-tag/2003Jul/0051.html
     [33] http://lists.w3.org/Archives/Public/www-tag/2003Jul/0113.html
     [34] http://www.w3.org/2001/tag/doc/whenToUseGet-20030709.html
     [35] http://www.w3.org/2001/tag/ilist.html#whenToUseGet-7
     [36] http://www.w3.org/2001/tag/ilist.html#putMediaType-38
     [37] http://lists.w3.org/Archives/Public/www-tag/2003May/0099.html
     [38] http://www.w3.org/2001/tag/open-summary.html#metadataInURI-31
     [39] http://www.w3.org/2001/tag/doc/metaDataInURI-31
     [40] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0151.html
     [41] http://www.w3.org/2001/tag/ilist#xmlIDSemantics-32
     [42] http://www.w3.org/2001/tag/doc/xmlIDSemantics-32.html
     [43] http://www.w3.org/2001/tag/open-summary.html#contentPresentation-26
     [44] http://www.tbray.org/ongoing/When/200x/2003/04/30/AppleWA

  3.2 Other new issues?

   The TAG did not discuss the following, and does not expect to discuss
   this issue at its ftf meeting in Vancouver.
    1. [45]Meaning of URIs in RDF documents, raised by TBL

     [45] http://lists.w3.org/Archives/Public/www-tag/2003Jul/0022.html

  3.3 Issues with action items

   The TAG does not expect to discuss these.
     * [46]uriMediaType-9
          + IANA appears to have responded to the spirit of this draft
            (see [47]email from Chris Lilley).What's required to close
            this issue?
          + Action CL 2003/05/05: Propose CL's three changes to
            registration process to Ned Freed. [What forum?]
     * [48]HTTPSubstrate-16
          + Action RF 2003/02/06: Write a response to IESG asking whether
            the Web services example in the SOAP 1.2 primer is intended
            to be excluded from RFC 3205
          + See [49]message from Larry Masinter w.r.t. Web services.
     * [50]xlinkScope-23
          + See [51]draft, and [52]SW message to CG chairs.
          + Action CL 2003/06/30: Ping the chairs of those groups asking
            for an update on xlinkScope-23.
     * [53]binaryXML-30
          + Action TB 2003/02/17: Write to www-tag with his thoughts on
            adding to survey.
          + Next steps to finding? See [54]summary from Chris.
     * [55]xmlFunctions-34
          + Action TBL 2003/02/06: State the issue with a reference to
            XML Core work. See [56]email from TimBL capturing some of the
     * [57]siteData-36
          + Action TBL 2003/02/24 : Summarize siteData-36

     [46] http://www.w3.org/2001/tag/open-summary.html#uriMediaType-9
     [47] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0302.html
     [48] http://www.w3.org/2001/tag/open-summary.html#HTTPSubstrate-16
     [49] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0208.html
     [50] http://www.w3.org/2001/tag/ilist.html#xlinkScope-23
     [51] http://lists.w3.org/Archives/Member/tag/2003Mar/0094.html
     [52] http://lists.w3.org/Archives/Member/tag/2003Mar/0104
     [53] http://www.w3.org/2001/tag/open-summary.html#binaryXML-30
     [54] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0224.html
     [55] http://www.w3.org/2001/tag/ilist#xmlFunctions-34
     [56] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0309.html
     [57] http://www.w3.org/2001/tag/ilist.html#siteData-36

  3.4 Issues the TAG intends to discuss at face-to-face meeting


     * [58]URIEquivalence-15
          + SW proposal: Track RFC2396bis where [59]Tim Bray text has
            been integrated. Comment within the IETF process. Move this
            issue to pending state.
     * [60]IRIEverywhere-27
          + Action CL 2003/04/07: Revised position statement on use of
          + Action TBL 2003/04/28: Explain how existing specifications
            that handle IRIs are inconsistent. [61]TBL draft not yet
            available on www-tag.
          + See TB's[62]proposed step forward on IRI 27.

     [58] http://www.w3.org/2001/tag/open-summary.html#URIEquivalence-15
     [59] http://www.textuality.com/tag/uri-comp-4
     [60] http://www.w3.org/2001/tag/open-summary.html#IRIEverywhere-27
     [61] http://lists.w3.org/Archives/Member/tag/2003Apr/0074.html
     [62] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0090.html

    Qnames, fragments, and media types

     * [63]rdfmsQnameUriMapping-6
          + Action DC 2003/02/06: Propose TAG response to XML Schema
            desideratum ([64]RQ-23).
     * [65]fragmentInXML-28 : Use of fragment identifiers in XML.
         1. Connection to content negotiation?
         2. Connection to opacity of URIs?
         3. No actions associated / no owner.
     * [66]abstractComponentRefs-37
          + See [67]issue description from David Orchard. Next steps?
          + Action DO 2003/06/23: Point Jonathan Marsh at options. Ask
            them for their analysis.
     * [68]putMediaType-38

     [63] http://www.w3.org/2001/tag/open-summary.html#rdfmsQnameUriMapping-6
     [64] http://www.w3.org/TR/2003/WD-xmlschema-11-req-20030121/#N400183
     [65] http://www.w3.org/2001/tag/ilist#fragmentInXML-28
     [66] http://www.w3.org/2003/07/24-tag-summary.html#abstractComponentRefs-37
     [67] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0089.html
     [68] http://www.w3.org/2001/tag/open-summary.html#putMediaType-38

    RDDL, namespace documents

     * [69]namespaceDocument-8
          + Action TB 2003/04/07: Prepare RDDL Note. Include in status
            section that there is TAG consensus that RDDL is a suitable
            format for representations of an XML namespace. Clean up
            messy section 4 of RDDL draft and investigate and publish a
            canonical mapping to RDF. See TB's [70]1 June version.
          + Action PC 2003/04/07: Prepare finding to answer this issue,
            pointing to the RDDL Note. See [71]comments from Paul
            regarding TB theses.
          + Refer to draft TAG [72]opinion from Tim Brayon the use of
            URNs for namespace names.
               o RF: Folks assume that because the specs say so, URNs
                 will be persisitent. But persistence is a function of
                 institutional commitment and frequency of use.

     [69] http://www.w3.org/2001/tag/open-summary.html#namespaceDocument-8
     [70] http://www.tbray.org/tag/rddl/rddl3.html
     [71] http://lists.w3.org/Archives/Member/tag/2003Apr/0046.html
     [72] http://lists.w3.org/Archives/Public/www-tag/2003Jun/0003.html

    Other actions

     * [73]RDFinXHTML-35
     * [74]mixedUIXMLNamespace-33
     * [75]errorHandling-20
          + Action CL 2003/02/06: Write a draft finding on the topic of
            (1) early/late detection of errors (2) late/early binding (3)
            robustness (4) definition of errors (5) recovery once error
            has been signaled. Due first week of March.

     [73] http://www.w3.org/2001/tag/open-summary.html#RDFinXHTML-35
     [74] http://www.w3.org/2001/tag/open-summary.html#mixedUIXMLNamespace-33
     [75] http://www.w3.org/2001/tag/open-summary.html#errorHandling-20

4. Other actions

     * Action IJ 2003/02/06: Modify issues list to show that
       actions/pending are orthogonal to decisions. IJ and PLH making
       substantial progress on this; hope to have something to show in


    Ian Jacobs for Stuart Williams and TimBL
    Last modified: $Date: 2003/07/15 00:36:20 $

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

Received on Monday, 14 July 2003 20:49:55 UTC