W3C home > Mailing lists > Public > www-tag@w3.org > June 2004

[Minutes] 7 Jun 2004 TAG teleconf (xml11Names-46, httpRange-14, LC: kopecky5, hawke3, hawke7)

From: Ian B. Jacobs <ij@w3.org>
Date: Mon, 07 Jun 2004 16:28:38 -0500
To: www-tag@w3.org
Message-Id: <1086643718.13607.328.camel@seabright>

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

 - Ian

[1] http://www.w3.org/2004/06/07-tag-summary.html

                   Minutes of 7 June 2004 TAG teleconference

1. Administrative

    1. Roll call. All present: SW (Chair), TBL, CL, PC, MJ, RF, DC, NW,
       IJ (Scribe).
    2. Resolved: Accepted the [8]minutes of the 12-14 May F2F
    3. Resolved: Accepted the [9]minutes of the 24 May teleconference
    4. Accepted this [10]agenda
    5. Resolved: Next meeting: 14 June. Chair: NW. Regrets: SW, TBL, IJ.
    6. Action TBL 2004/05/12: Talk to TB and DO about editor role.

      [8] http://www.w3.org/2004/05/14-tag-summary.html
      [9] http://www.w3.org/2004/05/24-tag-summary.html
     [10] http://www.w3.org/2004/06/07-tag.html

  1.1 Future meetings

    1. 5 July 2004 TAG teleconference at risk. Regrets: PC
    2. Resolved to hold ftf meeting in Basel 5-7 October 2004. RF to
       follow up on meeting organization.
    3. August ftf meeting in Ottawa: PC will send hotel information to
       TAG; more info in [11]IRC log.
    4. Discussion postponed: AC meeting [12]rescheduled for 2-3 December.
       Does this affect whether to hold TAG ftf meeting in November?
    5. Regrets:
         1. SW: I'll be unavailable from 19 July to 9 Aug.
         2. PC: Regrets 28 June and 5 July.
       Action TAG: Send summer regrets to TAG list.: Send summer regrets
       to TAG list.

     [11] http://www.w3.org/2004/06/07-tagmem-irc.html
     [12] http://lists.w3.org/Archives/Member/chairs/2004AprJun/0050.html

  1.3 TAG Charter

   Action IJ: Report back on next AB meeting to discuss TAG charter and
   relation to patent policy.

2. Technical

   See also [13]open actions by owner and [14]open issues.

     [13] http://www.w3.org/2001/tag/actions_owner.html
     [14] http://www.w3.org/2001/tag/issues.html?view=normal&closed=1

  2.1 Possible New Issues

    1. [15]XML 1.1 Question from XMLP-WG

     [15] http://lists.w3.org/Archives/Public/www-tag/2004May/0039.html


          [PC summarizing]
          PC: Qnames in xschema broken by xml 1.1.

          "broken"? an example scenario would help

          PC: I propose that the tag adopt this as an issue and then push
          to xml activity.

          A QName using an XML 1.1 character cannot be validated with
          Schema 1.0

          PC: I suggest that the TAG not spend lots of time on this.

          Characters in Names is the more general issue

          NW: I agree that we should adopt an issue and hand it off to
          CL: I agree with PC's plan generally, and sending it to XML CG
          appropriate. I agree with NW that this is wider than schema.

          DanC, you wanted to ask why this belongs on the TAG issues
          list, and shouldn't be handled by XML foo?

          DC: How does this impact architecture?

          xml is architectural

          NW: I think that this goes beyond xml (e.g., n3)
          TBL: n3 doesn't make reference to the bnf in the xml spec.

          true, links *into* xml are affected

          CL: I think this is of the same ilk as the xml id issue.
          PC: XML CG likely to accept this issue from the TAG.
          NW: Take an xml doc that contains a qname that has one of the
          new unicode characters in it (i.e., in xml 1.1, not in xml
          1.0). Now try to put an xpointer in a document that uses a
          qname. Which version of qnames does it use for the local name
          DC: Did people see this coming at PR?
          PC: Yes.
          NW: I think W3C made the right decision, but that some loose
          ends need to be tied down. I am for adopting the issue, then
          helping getting it fixed.
          TBL: The way that [16]xml 1.1 was presented was that it should
          only be used "when necessary."

     [16] http://www.w3.org/TR/xml11/

          NW: Necessary, e.g., if you want to create documents in
          Ethiopian language.

          Suppport for new issue: RF, CL, NW, PC, TBL, MJ. Abstaining:
          DC, SW.

          Resolved to accept new TAG issue xml11Names-46

          Action NW: Write up the issue for the TAG. If there are no
          objections to formulation, forward to the XML CG on behalf of

  2.2 httpRange-14 status

   Action TBL/RF 2004/05/13: Write up a summary position to close
   httpRange-14, text for document.


          RF: There is no proposed resolution on the uri mailing list
          that any two people can firmly agree to. See [17]thread and
          [18]another thread started by Larry Masinter.
          SW: The title of RFC2396 concerns generic syntax...
          RF: IANA requirements require a bit more than that. I also need
          to incorporate (into RFC2396bis) comments in and
 The latter needs to go into the RFC since it doesn't
          really make sense in an informational draft. Those are both
          cut-and-paste actions.: The spec has primarily been held up due
          to travel, not the definition. The spec won't progress with the
          current defn; I don't know what the change will be to enable
          progression.: Proposing concrete text would help.
          DC: I was a bit surprised at direction of discussion.
          RF: The issue looks resolvable; finding the right words is the
          problem. Lots of disagreement about definition of "resource".
          In my opinion, it seems that people are confused about what a
          resource is and what it can be. Not sure whether progress will
          be (1) clearer understanding or (2) less present definition. I
          don't see obstacles to consensus, but discussion has not

     [17] http://lists.w3.org/Archives/Public/uri/2004May/thread.html#26
     [18] http://lists.w3.org/Archives/Public/uri/2004May/thread.html#50

          No resolutions or new actions.

  2.3 Web Architecture Document Last Call

   IJ: Next editor's draft expected 8 June 2004.

   No progress on these actions from 2004/05/14:
     * Action NW: Propose text on tradeoffs for section 4.2.2.
     * Action CL: Rewrite story at beginning of 3.3.1. Consider deleting
       para that follows last sentence third para after story in 3.3.1.
       "Note also that since dereferencing a URI (e.g., using HTTP) does
       not involve sending a fragment identifier to a server or other
       agent, certain access methods (e.g., HTTP PUT, POST, and DELETE)
       cannot be used to interact with secondary resources."

    LC Issue kopecky5

   [19]Issue kopecky5

     [19] http://www.w3.org/2001/tag/2003/lc1209/issues.html#kopecky5


          DC: I mailed him; see his 3[20]0 March response which includes
          a clarification.
          IJ: I am planning on including similar text in tomorrow's draft
          and will endeavor to tie in his points re: qnames.
          Resolved: Close DC's action for kopecky 5.

     [20] http://lists.w3.org/Archives/Public/public-webarch-comments/2004JanMar/1071.html

          IJ: The relevant sentence I'm drafting: "One particularly
          useful mapping is to combine the namespace URI, a hash ("#"),
          and the local name, thus creating a URI for a secondary
          resource (the identified term)."

          I would add "(assuming the namespace is flat)" somewhere, i.e.,
          the mapping is only useful when the namespace is flat.

          DC: Also mention the one that has more wrinkles - [21]schema
          component designators.

     [21] http://www.w3.org/TR/2004/WD-xmlschema-ref-20040309/

   PC leaves.

    LC Issue stickler7

   [22]Issue stickler7

     [22] http://www.w3.org/2001/tag/2003/lc1209/issues.html?view=normal&closed=1#stickler7

   IJ: I believe that tomorrow's Editor's Draft will address stickler7.

    LC Issue hawke3

   [23]Issue hawke3

     [23] http://www.w3.org/2001/tag/2003/lc1209/issues.html?view=normal&closed=1#hawke3


          IJ: I've incorporated his changes into the section on [24]URI
          ownership. Specifically: "The generation of a fairly large
          random number or a checksum reduces the risk of URI overloading
          to a calculated small risk. A draft "uuid" scheme adopted this
          approach; one could also imagine a scheme based on md5
          DC: s/fairly//

     [24] http://www.w3.org/2001/tag/2004/webarch-20040510/#uri-ownership

          DC: I propose to either (1) move to future directions or (2)
          strike the bits about uuid and md5

          neither uuid nor mmdf are used because they do not prevent

          its future or non-adopted work, so does not conflict with tag
          to use only registered schemes
          support moving to futre directions, unless we think its a
          failed approach

          DC: I'd rather strike than move to future directions at this
          RF: I'd remove it.
          CL: I'd move to future directions.

          support removing it also; not hearing that its likely future

          RF: I don't consider these to be identifiers. md5, e.g.,
          doesn't prevent collisions, but reduces risk. Given a document
          repository the size of the web, there is a guarantee that there
          are colliding docs on the web.
          TBL: UUIDs have a delegated part.
          RF: If properly constructed, yes.

          rf also said that its fragile, any edit to the resource gives a
          new uuid

          RF: If properly constructed, have same properties as mid
          MJ: Large random numbers are unwieldly.
          TBL: Large random numbers technically work, but raise social

          tim, yes, lots of things might be interesting in the fullness
          of time. meanwhile, nobody has done the homework to finish the
          uuid: scheme. Let's strike discussion of it, no?

          IJ propose: delete second bullet and mention large numbers in
          third bullet; delete uuid and md5

          Mario, that was my point exactly, its a theoretical example

          TBL: Say "hypothetical"?


          SW: Who would like to see the middle example on large numbers


          CL: strike
          SW: strike

          TBL: Concur

          you'll have to tweak "the above approaches". Note that mid/cid
          also use domain names (the hierarchical part); the number part
          looks like a file name.

          Action IJ: Remove the middle bullet from 2.3.

    LC Issue hawke7

   [25]Issue hawke7

     [25] http://www.w3.org/2001/tag/2003/lc1209/issues.html?view=normal&closed=1#hawke7


          IJ: I note for hawke6 that we talked about at ftf and didn't

          IJ: I've put SH's text in section 2.7.2: Assertion that Two
          URIs Identify the Same Resource. I believe some folks commented
          on this text at the ftf meeting.
          TBL: In RDF, sameAs applies to resources.

          <http://weather.example.org/stations/oaxaca#ws17a"> owl:sameAs

          no, I can't endorse "Note also that to URIs that are sameAs one
          another ...

          RF, SW: I don't follow this para.
          TBL: I think that reviewer is saying: "If two URIs identify the
          same resource, that doesn't mean that you can use them
          DC: Yes it does.
          TBL: Suppose you use "#" in both of them; so they both refer to
          the same weather station. Sandro is saying that you can, e.g.,
          put one or the other in an RDF statement. But if you
          dereference them you'll get different information back.
          SW suggests a a response  la Pat Hayes: The two URIs denote
          the same resource but identify two different information
          TBL: We use "identify" in the arch doc, not "denote".
          IJ: What about s/interchangeable/interchangeable for purposes
          other than identification/ ?
          DC: I don't think this point is worth making (and furthermore,
          I don't believe it).

          Any argument that says something would be true for URIs of one
          scheme that's false for URIs of another scheme makes me wince

          DC: The resources are interchangeable, the URIs are spelled
          TBL: But it makes a difference which one you use. If SH
          intentionally didn't use a "#" in the second URI, then I don't
          understand his question.
          Proposed: Ask SH for clarification - was "#" dropped by mistake
          in second URI?

          Action TBL: Ask Sandro for clarification on whether second URI
          should have "#".

   After the meeting, TBL fulfilled his action on IRC; the following is
          the relevant excerpt:

   TBL: Sandro, I thought your comment was not about hashses but others
          thought it was.

   Sandro Hawke: It is NOT about hashes at all. It's at the level of
          owl:sameAs, where hashes are irrelevant.

   TBL: I thought it was that even though two URIs (say with hashes)
          identify the same thing, they deref to different resources, so
          it makes a difference which one you use in communication.

   Sandro Hawke: Exactly


   The TAG did not expect to discuss issues below this line.

   Completed action items:
    1. Action IJ 2004/05/24/: Announce the closure of issue
       URIEquivalence-15. See [26]proposal to drop this action.

     [26] http://lists.w3.org/Archives/Member/tag/2004May/0070.html

   Actions 2004/03/15 (due 25 March?) to review sections:
     * Norm: I volunteer for section 3 ([27]Proposed)
     * TBL: I volunteer 2 hours starting at start of section 2
     * Roy: I volunteer to look at section 2
     * Stuart: I volunteer starting at section 2.3
     * Mario: I will look at section 4

     [27] http://lists.w3.org/Archives/Public/www-tag/2004Apr/0011.html

3. Status report on these findings

   See also [28]TAG findings
     * [29]abstractComponentRefs-37:
          + 30 Oct 2003 draft finding "[30]Abstract Component References"
     * [31]contentPresentation-26:
          + 30 June 2003 draft finding "[32]Separation of semantic and
            presentational markup, to the extent possible, is
            architecturally sound"
     * [33]metadataInURI-31
     * [34]siteData-36
          + "[35]There is no such thing as a Web site"

     [28] http://www.w3.org/2001/tag/findings
     [29] http://www.w3.org/2001/tag/issues.html#abstractComponentRefs-37
     [30] http://www.w3.org/2001/tag/doc/abstractComponentRefs-20031030
     [31] http://www.w3.org/2001/tag/open-summary.html#contentPresentation-26
     [32] http://www.w3.org/2001/tag/doc/contentPresentation-26-20030630.html
     [33] http://www.w3.org/2001/tag/open-summary.html#metadataInURI-31
     [34] http://www.w3.org/2001/tag/issues.html#siteData-36
     [35] http://www.tbray.org/ongoing/When/200x/2004/01/08/WebSite36

4. Other action items

     * Action DC 2003/11/15: Follow up on KeepPOSTRecords with Janet Daly
       on how to raise awareness of this point (which is in CUAP).
     * Action CL 2003/10/27: Draft XML mime type thingy with Murata-san


    Ian Jacobs for Stuart Williams and TimBL
    Last modified: $Date: 2004/06/07 21:21:21 $

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

Received on Monday, 7 June 2004 17:28:39 UTC

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