W3C home > Mailing lists > Public > www-tag@w3.org > January 2003

[Minutes] 27 Jan 2003 TAG teleconf (httpRange-14, arch doc, IRIEverywhere-27, binaryXML-30, xmlProfiles-29)

From: Ian B. Jacobs <ij@w3.org>
Date: Mon, 27 Jan 2003 20:20:48 -0500
Message-ID: <3E35DAF0.9010905@w3.org>
To: www-tag@w3.org


Minutes of the 27 Jan 2003 TAG teleconf available as
HTML [1] and as text below.

  - Ian

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


                    Minutes of 27 Jan 2003 TAG teleconference

    Nearby: [4]IRC log | [5]Teleconference details  [6]issues list 
    [7]www-tag archive

       [4] http://www.w3.org/2003/01/27-tagmem-irc.html
       [5] http://www.w3.org/2001/tag/group/#remote
       [6] http://www.w3.org/2001/tag/ilist
       [7] http://lists.w3.org/Archives/Public/www-tag/

1. Administrative (20min)

     1. Roll call: SW (Chair), DC, PC, RF, CL, TB, DO, IJ. Regrets: TBL,
     2. Accepted [8]20 Jan minutes
     3. Accepted this [9]agenda
     4. Next meeting: 3 Feb (short)

       [8] http://www.w3.org/2003/01/20-tag-summary.html
       [9] http://www.w3.org/2003/01/20-tag.html

   1.1 Meeting planning

   1.2 FTF meeting agenda

      * Next TAG ftf: 6-7 Feb 2003 in Irvine, CA (USA)
           + [10]Draft agenda and [11]straw poll for agenda items
           + SW: I expect to send agenda by close of business Weds this
             week. Please read [12]editor's draft of Arch Doc to prepare
             for FTF meeting
           + Nov 2003: Face-to-face meeting in Japan on 17 Nov?

      [10] http://www.w3.org/2003/02/06-tag-agenda.html
      [11] http://lists.w3.org/Archives/Member/tag/2003Jan/0071.html
      [12] http://www.w3.org/2001/tag/2002/webarch-20021206

   1.3 TAG at tech plenary


           DO: Tech plenary planning committee has met.

           "short" and "5 segments" don't both fit in my brain at the same

           CL: Good idea to pick top three issues and get input. XML id,
           XML subsetting good.
           DO: We'll use BOF to talk about linking.
           [Discussion of fact that xml id and xml subsetting orthogonal.]
           PC: Looking to have 90 minutes with non-TAG moderator. The
           message is that people want more technical content.
           DO: I was hoping to have no process discussion; we'll have a
           short discussion.

           I'd be happy letting any process discussion come up as Q&A.

           I think 10 mins is an acceptable compromise but lets hold it to
           that and not let it spread into the technical part

           DanCon, you wanted to ask about discussion mode/logistics
           (panel? presentations? other?)

           PC: I think Steve Zilles should moderate.
           DO, CL: Good idea.
           Confirmed to attend and participate: CL, DC, PC, DO
           LIkely regrets: TB, RF, SW
           PC: NW should be there since he'll be there that week for XSL

    [Defer discussion to ftf meeting]

2. Technical

      * 2.1 [13]httpRange-14
      * 2.2 [14]Architecture Document
      * 2.3 [15]IRIEverywhere-27
      * 2.4 [16]binaryXML-30
      * 2.5 [17]xmlProfiles-29

   2.1 httpRange-14

     1. httpRange-14:
          1. [18]Request to establish the relationship between URIs and
             Resources is many to many; from Bill de Hora.

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


           DC: I feel no obligation to discuss this in previous meetings.

           what Dan said

           CL: BDH's question has not been ignored on the list.
           TB: In light of further traffic on www-tag (and xml-dev in
           parallel), my opinion has gotten stronger that our chances for
           consensus on this point are small. I agree that TBL's world
           view is consistent; I just don't believe it.
           IJ: I think this issue may be blocking us in practice, even if
           we have said in the past it's not critical path.
           DO: I don't know what new information there has been to cause
           us to reopen this.

           I agree on the 'what text needs to change' criterion

           RF: I've spent a lot of time drafting messages; they had
           nothing to do with httpRange-14 except in the periphery. The
           purpose of those messages was to establish what we should put
           in the arch doc. If TBL wants to describe the Web as everything
           the W3C is doing, we have to write another document. We need to
           write a model that describes it all. The REST model does not
           describe the SemWeb architecture.: The reason we have to make a
           choice: I can describe the system that exists without talking
           about anything in the future (by looking at implementations).
           Whether we want to talk about the future will affect our
           DO: There is similar discussion going on in Web Services area.

           but if there are no implementations in that area, isn't it
           premature to try and abstract out their properties?

           [Agreement to talk about "What should go in the arch doc" at
           the ftf meeting.]
           PC: I think it's important that at our ftf, we talk about
           www-tag and perhaps a need to organize threads.
           SW: We shan't discuss httpRange-14 today; will not be on agenda
           any time soon.

   2.2 Architecture document

     1. [19]6 Dec 2002 Editor's Draft of Arch Doc:
          1. Next TR page draft? IJ proposes after ftf meeting.
          2. Action CL 2002/09/25: Redraft section 3 based on resolutions
             of [20]18 Nov 2002 ftf meeting.
          3. Complete review of TBs [21]proposed principles CP9, CP10 and

      [19] http://www.w3.org/2001/tag/2002/webarch-20021206
      [20] http://www.w3.org/2002/11/18-tag-summary#archdoc
      [21] http://lists.w3.org/Archives/Public/www-tag/2002Nov/0107.html

           CL: I've started putting together a chapter three. I will have
           something shortly before the ftf meeting. I'll try to have
           enough in advance to read on plane.

    The TAG reviewed proposed principles CP9, CP10, and CP11 raised at
    [22]November 2002 ftf meeting

      [22] http://lists.w3.org/Archives/Public/www-tag/2002Nov/0107.html

           CP9. Designers of protocols should invest time in understanding
           the REST paradigm and consider the role to which its principles
           should guide their design:
           - statelessness
           - clear assignment of roles to parties
           - flat addrss space
           - limited uniform set of verbs

           yes, agreed

           DC: Are these the top four things for REST?
           RF: Say "Uniform address space" instead of "flat address
           DC: I have no objection to this, but would rather explain how
           to do a Web page / how not to. I'd be willing to write
           something up.

           ACTION DC write two pages on correct and incorrect application
           of REST to an actual web page design

           (I was talking about a finding... webarch editor to steal as
           much/little text as he likes)

           or a web service

           agree with Roy s/flat/uniform/

           note to self: OpenGIS mapping service is a *great* example of a
           straightforward "uniform address space" service

           DO: I'm writing something in Web Services area that's related.
           DO: I'd have to publish this info....
           DO: My goal is different - someone who believes in REST can say
           "this is how I would build a REST-based Web service" and
           someone more interested in RPC could do things according to
           that style.
           ACTION DO: Please send writings to tag@w3.org. DO grants DC
           license to cut and paste and put into DC writing.
           TB: Per our charter, please send info to www-tag.
           RF: One reason is that we are talking about WS Arch....
           TB: Ok, but I'll keep pushing for www-tag.
           Resolved: Accept CP9 with s/flat/uniform.
           CP10. Agents which receive a resource representation
           accompanied by an Internet Media Type MUST interpret the
           representation according to the
           semantics of that Media Type and other header information.
           Servers which generate representations MUST not generate Media
           Types and other header information (for example charsets)
           unless there is certainty that the headers are correct.
           CL: +1 to add this as is

           IJ: See related language in [23]Internet Media Type
           registration, consistency of use:
           "The architecture of the Web depends on applications making
           dispatching and security decisions for resources based on their
           Internet Media Types and other MIME headers. It is a serious
           error for the response body to be inconsistent with the
           assertions made about it by the MIME headers. Web software
           SHOULD NOT attempt to recover from such errors by guessing, but
           SHOULD report the error to the user to allow intelligent
           corrective action."
           CL: I like the more general second sentence of CP10 (compared
           to findnig). I can elaborate this; and give examples.

      [23] http://www.w3.org/2001/tag/2002/0129-mime

           I can elaborate this no problem

           DC: I prefer what we have in the finding. wget and link
           checkers don't pay attention to the mime type, and they're
           still correct.

           they are not, arguably correct

           DanCon, you wanted to wonder about clients like WGET that
           totally ignore MIME types, in a way that's good.

           DanC: ... and so the way it's phrased here in CP10
           ml doesn't appeal to me.

      [24] http://lists.w3.org/Archives/Public/www-tag/2002Nov/0107.html

           IJ: I think there is an ok behavior where the tool says "I'm
           doing something different." This is different than a user agent
           doing something and hiding it's incorrect behavior.
           TB: I support moving finding info into arch doc. I think we
           need to say more about "Servers which generate representations
           MUST not generate Media Types and other header information (for
           example charsets) unless there is certainty that the headers
           are correct." in arch doc.
           RF: One slight problem - because of some charset interpreting
           errors in some browsers, often the charset is explicitly given
           in the doc itself to prevent a cross-site scripting security
           TB: If you are sending well-formed XML, it knows what charset
           it's in. It's almost always wrong to say what the charset is
           (and you could get it wrong)

           I understand this and can write it in the arch doc

           TB: Don't serve as text/xml; transcoders can possibly get it
           ACTION CL: Draft language for arch doc that takes language from
           internet media type registration, propose for arch doc, include
           sentiment of TB's second sentence from CP10.
           CP11. Designers of protocols should give serious consideration
           to avoiding such design activities in favor of existing
           protocols such as HTTP that fit well into REST.
           TB: Another way to say this is : Avoid designing new protocols
           if you can accomplish what you want with HTTP
           DC: I think that TBL has an old action to build a table saying:
           what patterns would imply appropriate protocols.
           TB, IJ: We withdrew that action.
           TB: This is a statement worth making; people should think about
           using HTTP before running off to design a new protocol.
           DO: What are the criteria for using/not using?
           TB: That's a larger question that may be worth working on.
           DC: "In the Web context" is vague to me. The IETF best practice
           on record is "Don't use HTTP except for hypertext.": Handwaving
           won't help us here.
           TB: I have not understood why WebDev was needed as another
           RF: It's written as an extension to HTTP.
           DC: It runs on port 80.
           DC: My examples are POP and SMTP.
           Action TB: Develop CP11 more.
           DC: I suggest describing GET/PUT/POST in a para each, then say
           "if your app looks like that, use HTTP".

           TB: If your protocol needs a notion of a temporally extended
           session, then HTTP won't help you.
           DO rhetorically: Why would you need one of those? You'll need
           to include some examples.

   2.3 IRIEverywhere-27

     1. [25]IRIEverywhere-27
          1. Action MD and CL 2002/11/18: Write up text about
             IRIEverywhere-27 for spec writers to include in their spec.
          2. Action CL 2002/11/18: Write up finding for IRIEverywhere-27
             (from TB and TBL, a/b/c), to include MD's text. Process with
             IJ; awaiting comments from MD

      [25] http://www.w3.org/2001/tag/ilist#IRIEverywhere-27


           CL: IJ and I discussed this last week. We drew up some text.:
           Text based on input from Martin Duerst.
           DC: Value of treating e and E as equivalent is a huge cost.
           What actual value do you get?
           CL: Actual value is that both are equivalent to the same
           TB: Lots of software is already treating %7e and %7E as the

           that they are equivalent to the *actual character* represented
           uri spec is way fuzzy on this
           actual practice is that they are the same

           TB: Per 2396, I think Web robots are in their rights; lots of
           Web robots do this.
           RF: Yes, that's my understanding.
           PC: Chris, could you explain impact?

           I think it's straightforward to read the URI spec as saying
           that [26]http://a/%7E and [27]http://a/%7e are distinct URIs,
           and may or may not refer to the same resource.
           roy, you think otherwise?

      [26] http://a/%7E
      [27] http://a/%7e

           I think otherwise

           I read it the same as Dan :-(

           CL: There is a bigger effect on IRI spec and suggestions for

           sigh; each of those URIs is a sequence of 12 characters. they
           differ in their 12th character. hence they're different URIs.
           RFC2396 says otherwise?

           this has more effect on IRI comparison (which is done by
           transformation to URI and then comparing)

           Action CL: Please propose text IJ and CL worked on to www-tag
           (flipping the ACL).

           %7e is one character -- three octets

           it means that the *actual kanji* and the sequence of hexifyied
           octets compare to the same
           which helps in roundtripping a very great deal

           oops one octet -- char[$1\47]

           "%7e" is *one* character???

           "character" is defined in spec

           was ignoring IRC... yes, lots of software will decide those two
           URIs are the same in their cache

           no, %7e is one octet

           hence *sequence of *

    DanCon, you wanted to suggest the value of having %7E specified to be
           equivalent to %7e is purely aesthetic, and not *nearly* worth
           the cost.

   2.4 binaryXML-30

     1. [28]binaryXML-30
          1. Action CL 2002/12/02: Write up problem statement about binary
             XML; send to www-tag. See [29]CL email to tag

      [28] http://www.w3.org/2001/tag/ilist#binaryXML-30
      [29] http://lists.w3.org/Archives/Member/tag/2003Jan/0067.html


      [30] http://lists.w3.org/Archives/Member/tag/2003Jan/0074.html

           TB: I agree that a general public service announcement along
           the lines of what CL has done would be beneficial.

           yes, chris's msg is the first 80% of a finding, IMO.

           TB: I propose that we close the issue; no substantive proposal
           at this time. TB summarizing CL mail: The only out there that
           seems to be making a serious reach at being a broad-spectrum
           solution is the BIM thing.
           CL: I'd like to post this so that people can say "You aren't
           aware of this other thing...."
           DC: I'd like a week to think about the proposal.

           so, getting public review would flush out some alternative
           solutions we have missed

           DanCon, you wanted to ask for a week or so to consider Bray's

           Action CL: Send email 0067 to www-tag for feedback.
           TB: I will be astounded if a proposal comes forward that really
           does meet a broad spectrum of needs. Some requirements are
           fairly contradictory with each other.
           SW: We'll likely discuss this at the ftf meeting.

   2.5 xmlProfiles-29

     1. [31]xmlProfiles-29
          1. See email from Chris on [32]options for ID
          2. See email from NW (TAG-only) on [33]ID attributes.
          3. See [34]comments from Paul Grosso to treat xml:id as separate
          4. See [35]NW summary.

      [31] http://www.w3.org/2001/tag/ilist#xmlProfiles-29
      [32] http://lists.w3.org/Archives/Public/www-tag/2003Jan/0025.html
      [33] http://lists.w3.org/Archives/Member/tag/2003Jan/0013.html
      [34] http://lists.w3.org/Archives/Public/www-tag/2003Jan/0024.html
      [35] http://lists.w3.org/Archives/Public/www-tag/2003Jan/0178.html

           TB: Was there much disagreement about this?
           DO: My pushback was attribution; I don't think there's
           consensus in the TAG yet. NW wrote his note as NW's position,
           not TAG position.
           DC: I expect that NW will integrate feedback on his position.
           At the last meeting, we agreed to comment on NW's text.


      [36] http://lists.w3.org/Archives/Member/tag/2003Jan/0025.html

           TB: I don't think we have a TAG position without further
           discussion of NW's draft.

           Orchard hasn't responded in substance, has he? he only objected
           on process grounds. i.e. he hasn't sent his technical
           position/argument, did he?

           DO: I think that there are at least 3 or 4 people who could
           live with xml:id.
           TB: I thought we were trying to write a note for the AC on a
           way to proceed. My sense is that we pretty much agree with NW's
           draft except for the xml:id part.
           PC: I thought I saw public pushback on having profiles at all.


      [37] http://lists.w3.org/Archives/Public/www-tag/2003Jan/0191.html

           See also:
           TB: Mostly I see questions about SOAP and PIs. We could change
           "I feel strongly that it would be a mistake to introduce a
           single new feature, or a single change of any sort that would
           not be completely compatible with XML 1.1, in the work that
           subsets XML."
           "The question remains open..."
           DC: Seconded.

      [38] http://lists.w3.org/Archives/Public/www-tag/2003Jan/0217.html

           TB summarizes NW's conclusions.

           CL: That would mean that you cannot have xml:id; that's not in
           xml 1.0.
           TB: 1.1 processors would not know what it means, but wouldn't
           have any problems with it.
           SW: I'd like NW to concur with this.
           DC: I'm happy for him to do that after the fact.
           TB: My proposal is to ack that NW feels this way.
           DO: One possibility is to ask the AC what they think; another
           is to hammer this out further.
           TB: I think it's cost effective for us to tell the world that
           we think that there should be an xml 1.1.


      [39] http://lists.w3.org/Archives/Public/www-tag/2003Jan/0212.html

           DC: WRiting to the AC is logistically awkward. I recommend we
           write to XML Activity lead and recommend that it go to the

           DanCon, you wanted to ask that the chair put the question,
           including who we're writing to. Writing to the XML Activity
           lead, suggesting he take it to the AC, would be my preference

           Action IJ: Change one sentence, sent to XML Activity Lead, cc
           DO: I have some concerns about this; seems like we're pulling a
           fast one. I think we could do with more discussion about this.
           Perhaps we could do a straw poll on xml:id.
           TB: Why don't we accept a new issue on xml:id and get the ball
           PC/TB/DO agree.

           2nded, to accept an issue on xml:id (in case chair is counting
           toward majority in favor)

           DO: If we treat xml:id as a new issue, then ok to send out.
           Action DO: Raise new issue about xml:id (separate from
           DO: I will raise issue by tomorrow.
           TB PROPOSED: Close this issue with the sending of this letter.
           Resolved: Yes.

   Postponed: Findings in progress

    See also: [40]findings.
     1. Findings in progress:
          1. [41]deepLinking-25
               1. Action TB 2002/09/09: Revise "[42]Deep Linking" in light
                  of [43]9 Sep minutes.
          2. [44]URIEquivalence-15
               1. TB's "[45]How to Compare Uniform Resource Identifiers"
                  draft finding.
               2. Action TBL 2003/01/20: Send email to uri@w3.org
                  requesting terminology change (regarding definition of
               3. Action TB: Before Feb 2003, produce a new draft of
                  [46]How to Compare Uniform Resource Identifiers that
                  incorporates comments from DC and TAG.

      [40] http://www.w3.org/2001/tag/findings
      [41] http://www.w3.org/2001/tag/ilist#deepLinking-25
      [42] http://www.textuality.com/tag/DeepLinking.html
      [43] http://www.w3.org/2002/09/09-tag-summary
      [44] http://www.w3.org/2001/tag/ilist#URIEquivalence-15
      [45] http://www.textuality.com/tag/uri-comp-2.html
      [46] http://www.textuality.com/tag/uri-comp-2.html

   2.2 Priority issues

     1. [47]namespaceDocument-8
          1. Action PC, TB 2003/01/13: Write up a Working Draft that
             recommends a data format for namespace docs (not compulsory)
             and that such a document should follow the Rec track process.
             The initial content of the document should be taken from the
             RDDL challenge proposals; they are isomorphic in tecnical
             content. Please include drawbacks in the draft.
          2. Please read [48]NW summary of the following proposals:
               1. [49]RDDL Proposal from Tim Bray.
               2. [50]RDDL Proposal from Chris Wilper
               3. [51]RDDL Proposal from TBL
               4. [52]RDDL Proposal from Jonathan Borden
               5. [53]RDDL Proposal from Micah Dubinko
               6. [54]RDDL Proposal from Sandro Hawke
               7. See also [55]proposal from Garrett Wilson
     2. [56]fragmentInXML-28 : Use of fragment identifiers in XML.
          1. Connection to content negotiation?
          2. Connection to opacity of URIs?

      [47] http://www.w3.org/2001/tag/ilist#namespaceDocument-8
      [48] http://lists.w3.org/Archives/Public/www-tag/2003Jan/0004.html
      [49] http://lists.w3.org/Archives/Public/www-tag/2002Dec/0048.html
      [50] http://lists.w3.org/Archives/Public/www-tag/2002Dec/0056.html
      [51] http://www.w3.org/2002/11/rddl/
      [52] http://lists.w3.org/Archives/Public/www-tag/2002Dec/0099
      [53] http://lists.w3.org/Archives/Public/www-tag/2002Dec/0180.html
      [54] http://lists.w3.org/Archives/Public/www-tag/2002Dec/0232.html
      [55] http://lists.w3.org/Archives/Public/www-tag/2003Jan/0223.html
      [56] http://www.w3.org/2001/tag/ilist#fragmentInXML-28


     Ian Jacobs for Stuart Williams and TimBL
     Last modified: $Date: 2003/01/28 01:18:53 $

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447
Received on Monday, 27 January 2003 20:20:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:36 UTC