W3C home > Mailing lists > Public > www-tag@w3.org > July 2002

[Minutes] 29 July TAG teleconf (httpRange-14, URIEquivalence-15)

From: Ian B. Jacobs <ij@w3.org>
Date: Tue, 30 Jul 2002 08:38:03 -0400
Message-ID: <3D4688AB.8090803@w3.org>
To: www-tag@w3.org

Hello,

Minutes of the 29 July TAG teleconf are available
at HTML [1] and as text (below).

Next TAG teleconference: 12 August.

  _ Ian

[1] http://www.w3.org/2002/07/29-tag-summary

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

==========================================================
    W3C | TAG | Previous:22 Jul | Next: 12 Aug | IRC log

           Minutes of 29 July 2002 TAG teleconference

    Nearby: Teleconference details  issues list 
    www-tag archive

1. Administrative

     1. Roll call: DO, TB, TBL, DC, RF, CL, IJ. Regrets:
        NW, SW, PC
     2. Accepted 22 July minutes
     3. Accepted this agenda
     4. Next meeting? 12 Aug. Regrets: DO, CL
     5. September meeting arrangements
        Action TB: Send info about hotels to TAG. Done.

   1.2 Completed actions

     1. RF 2002/06/24: Write a paragraph on technical and
        political aspects of URIs and URI References.
        (done)
     2. DC 2002/07/08: Propose text for section 1.1 (URI
        Schemes). Done, see URI FAQ.
     3. Update and publish these findings as accepted.
        Action IJ and NW (done).
          1. Using QNames as Identifiers
          2. Consistency of Formatting Property Names,
             Values, and Semantics
     4. CL: Send copy of information sent to tag
        regarding RFC3023Charset-21 to www-tag. (Done)

2. Technical

     1. Findings, architecture document
     2. httpRange-14
     3. URIEquivalence-15
     4. Postponed

   2.1 Findings in progress, architecture document

    See also: findings.
     1. Architecture document
          1. Action CL 2002/07/08: Propose text for
             section 2 (Formats). (Sent to TAG; CL to
             publish).
          2. Action DC 2002/07/08: Ask IESG when they
             decided not to use HTTP URIs to name
             protocols.
          3. Action TBL (formerly assigned to DC): Create
             a table of useful URI properties.
          4. Action IJ 2002/07/08: Produce WD of Arch
             Doc. Harvest from DanC's URI FAQ. Deadline
             30 August.
     2. Internet Media Type registration, consistency of
        use.
           + Action PC 2002/07/08: Propose alternative
             cautionary wording for finding regarding
             IANA registration. Refer to "How to Register
             a Media Type with IANA (for the IETF tree) "

   2.2 httpRange-14

     1. httpRange-14: Need to make progress here to
        advance in Arch Document. See thread started by
        Tim Bray.
          1. Completed action SW 2002/07/22: Persuade
             TimBL to write an exposition of his position
             on httpRange-14. (Done; see TBL document).
             See also history of fragment ids from Roy.

    [Ian]
           TBL: In my doc, I explain why the alternatives
           don't work.
           DO: I'd like a week to read up on this.
           TB: If TBL convinces us that HTTP URIs are for
           docs only, where would we write this? What are
           the practical consequences? Where would this
           show up in the arch document if we agreed with
           TBL?
           TBL: s/resource/document, for example. So
           representations don't apply to mailboxes,
           e.g..
           TB: It would certainly add focus to the debate
           if we had some actual practical consequences.

    [ChrisL]
           TBL's HTTP-URI document seems to equate
           'document' and 'any collection of bits'
           TBL: Practical consequences:

          1. RDF Core would have to stop using
             doc-looking URIs to refer to some classes.

           RF: I am certain Dublin Core doesn't need to
           change.
           TBL: The URI of title has no hash, so is
           confusable between document/resource.
           RF: It doesn't matter.
           TBL: Before RDF, people haven't used URIs to
           refer to other things than web pages.

    [ChrisL]
           Never understood the RDF way of using # to
           mean "not za fragment identifier"

    [Ian]
           DC: There are namespace names.

    [ChrisL]
           People do indeed use URI to refer to things
           other than web pages.

    [Ian]
           TBL: If it doesn't affect the software, it's
           irrelevant philosophy.

    [ChrisL]
           No, the *definition* of dc.title has that
           length

    [Ian]
           DC: I would note that the XML Schema WG used
           URI refs to talk about data types. They use
           hash marks in them.
           RF: What about POST?

    [DanC]
           "aren't fragment identifiers"???

    [Ian]
           CL: This use of "#" as non fragment id's has
           always struck me as odd. Why is a fragment
           special?
           TBL: With and without a hash is fundamentally
           different. A URI Ref is a completely different
           animal than a URI. Need to look at another
           spec.
           CL: But the history is that these were the
           same thing.
           TBL: No, defined in same spec, but not the
           same thing. When you use "#" in an HTML doc,
           not a huge effect. But in RDF, a huge
           difference - takes you into abstract space.
           CL: I don't like the implication that non-RDF
           languages are non-semantic. What is good
           practice for using the "#"?
           TBL: You define that in the format spec, part
           of MIME registration.
           CL: Most specs other than RDF use sense of
           "fragment" (whether temporal or
           element-based).

    [DanC]
           really? there are ways to refer to 7 seconds
           into a video? I've been waiting for those, but
           haven't seen them.

    [DanC]
           [yet somehow, magically, calling it a
           "Document" precludes cars. Pls pick one side
           of your mouth to speak out of, timbl]

    [Ian]
           TBL: Ambiguity about owner's intent of what is
           identified.

    [ChrisL]
           WebCGM fragment syntax
           http://www.w3.org/TR/REC-WebCGM/REC-03-CGM-IC.
           html

    [Ian]
           DC: What if it's ambiguous but two things
           identified are identical?

    [ChrisL]
           SVG fragment identifiers
           http://www.w3.org/TR/SVG/linking.html#SVGFragm
           entIdentifiers

    [Ian]
           DC: Can you point to a car that's also a web
           page?
           TBL: For me that's incoherent.
           DC: But in common sense, you can't post to
           documents.
           TBL: Documents do not have a physical
           presence; cars do. No way I can determine
           whether I can use the URI to talk about a Web
           page since owner may have not meant it that
           way.

    [ChrisL]
           http://www.w3.org/TR/smil20/smil-timing.html#T
           iming-HyperlinkingTiming

    [Ian]
           RF: You can do this with RDF.

    [TBray]
           what Roy said

    [ChrisL]
           Hyperlinking and timing
           A hyperlink into or within a timed document
           may cause a seek of the current presentation
           time or may activate an element (if it is not
           in violation of any timing model rules).

    [Ian]
           TBL: But this won't retrofit to 10 billion
           existing web pages.
           RF proposal: Given lack of any other
           assertions, you can assume that a URI refers
           to a document. You are saying that because you
           don't have a default, therefore the entire
           HTTP namespace should be your lowest common
           denominator.
           TB: A URI is a string you can compare. An HTTP
           URI can be dereferenced. The Web arch doesn't
           allow you to know what the resource is. This
           is why RDF is a good thing. Allows you to make
           such assertions. Once you have RDF, I still
           don't see why you need to limit the range of
           HTTP URIs or other URI schemes.

    [DanC]
           my car is on the web.

    [Ian]
           CL: The car is a physical object, but it's not
           on the web. the concept is a title but is not
           on the web. You can point to the concept of
           "title". If you can point to "title", you can
           point to "car". I don't think you can point to
           a "title". You can point to a document where
           people say what they mean by title. Even with
           "#" you are pointing to a piece of a document.
           That piece may be an assertion. But could be
           pulled out and put in its own document, and I
           could refer to it without a "#".
           DC: You can always use the URI for a Web page.
           If the Webmaster has also said that that URI
           identifies a car, that's fine.
           TBL: When I do an HTTP transaction, can I
           store the results in RDF?
           DC: Yes. In the example of my Web page, the
           Web page is a car.
           TBL: What if a Web page talks about another
           Web page that talks about a car?
           http://myexample.org/mypage23 ->
           http://www.w3.org/mystuff -> car
           TBL: As author of the first URI I assert that
           it identifies the second page. I assert that
           they identify the same thing. Not sure that
           identical if you get different pages back from
           the Web.
           RF: The statement HTTP URIs identify documents
           is false.
           TBL: We are working out a consistent set of
           terms. If "document" is the wrong term, that's
           fine; we can work out another. I"m interesting
           in what machines can do.

    [ChrisL]
           I propose that Tim's definition of "document"
           is any bag of bits

    [Ian]
           RF: The software disagrees with you. I can't
           define proxies in your terms.
           TBL: You can: where you say "resource", say
           "document". It's sufficiently generic to cover
           your proxies.

    [DanC]
           If timbl really means that roy could
           s/resource/document/g, it's much cheaper for
           timbl to s/document/resource/g.

    [DaveO]
           heh

    [Ian]
           TBL: People think of the term "document" in a
           particular way, but that was the term as I
           originally intended (in an abstract sense).
           RF: What do "wais:" URIs identify? Search
           services. It's an information retrieval
           protocol.

    [ChrisL]
           so they identify a search engine

    [DanC]
           btw... timbl mentioned the cyc ontology; it
           really does have a wealth of nifty and
           relevant stuff on this topic...
           http://www.cyc.com/cycdoc/vocab/info-vocab.htm
           l

    [Ian]
           RF: When you access a wais resource through a
           proxy, you are saying - give me a
           representation of this resource through wais.

    [DanC]
           timbl:Document = cyc:ConceptualWork, I think.

    [ChrisL]
           (this is the general gatewaying problem, which
           was established at Cern)

    [Ian]
           DO: This is a point that has been skirted
           around -use of proxies. Could RF write up
           something on proxies?
           RF: I will read TBL's doc first.
           TB: Suppose I believe that DC's car URI really
           denotes DC's car. Suppose I write a bunch of
           stuff in RDF about the car, and I have a
           carfinder service online to sift among cars
           out there. All that is logical and
           self-coherent and causes no heartburn. Suppose
           RF doesn't believe it's a car but the URI
           identifies a Web page. He writes a bunch of
           other RDF that talks about the Web page. Our
           assertions are not interoperable but could be
           bridged with some metadata. But at the end of
           the day, so what? The idea that you will have
           universal agreement on what is identified is a
           chimera. But what's the difference?

    [ChrisL]
           (sounds like "do we assume all assertions are
           true")

    [Ian]
           TB: If we need to work together, we will do
           the work to understand each other.

           TBL: Cataclysmic interoperability problem is
           the heartburn.
           TB: That's the reality of life. You can't make
           it go away.

    [TimBL]
           You CAN

    [Roy]
           given any identifier, I can make a webpage out
           of it

    [Ian]
           TB: Another spin: suppose I want to make
           assertions that the Web page is a standin for
           W3C. Are Josh's views and mine that
           inconsistent? Perhaps on the surface, and we
           would need to work together. But I don't
           believe this problem can go away.
           TBL: You can make it go away. You can merge
           data when using same ontologies. The situation
           TB describes is frightfully messy to me. Where
           you have to do a massive conversion when
           merging data.

    [TimBL]
           x [ is fff of x ]
           x -> [ is fff of x ] mapiing woul dhave to be
           introdde between 2 incompatible webs
           Si
           <xml:lang="fr">si</>

    [DaveO]
           or <xml:lang="sp">si</> ?

    [ChrisL]
           <foo xml:lang="es">Si</foo> <!-- I suggest -->

    [TimBL]
           (On the contrary it does mean that TimBL's
           stuff breaks when Roy's data is introduced)

    [Roy]
           then it is already too broken to use

    [Ian]
           DC: TimBL wants a guarantee that someone will
           never find a car at the other end.

    [DanC]
           it's not "I can't know that". TimBL's saying
           "I consider that false."

    [Ian]
           RF: You need RDF to know what my URI
           identifies. If you want to be able to reason
           using this URI in an unambiguous manner, then
           you will need more information.
           IJ: Then what does it mean that a URI means
           the same thing in any context?

    [ChrisL]
           isn't this an arcrole to say how much
           dereferencing is happening?

    [Ian]
           TBL: In general, there is an axiom that a URI
           identifies one thing in all cases.

    [DanC]
           I don't believe that axiom any more, btw,
           timbl.

    [Ian]
           TBL: If you use a URI in a relationship, it
           can indirectly refer to other things.

    [ChrisL]
           except in the trivial case - it identifies the
           resource that you get by dereferencing it

    [DanC]
           Chris, that's one (coherent) position: there
           are different ways to point. *p vs **p, in a
           sense.

    [TimBL]
           Roy has said that he can't use TimBL's scheme
           because proxies won't work because he thinks
           tim's system has no difference between
           document an representation, but there he i
           swrong, presumbably because he hasn't read
           TimBL's stuff yet.

    [ChrisL]
           arcrole of "the organisation that published
           this page"

    [Ian]
           TB: I suggest we publish these logs and stand
           back and see what happens on www-tag.

    [ChrisL]
           as opposed to, say, arcrole of "the isp that
           hosts this page" or any other such arc role

    [DanC]
           In AaronSw's reply to TimBL
           (http://lists.w3.org/Archives/Public/www-tag/2
           002Jul/0319) I find much that I agree with.

    [Roy]
           Roy says that TimBL's document == resource and
           therefore it is confusing to call them
           documents

   2.3 URIEquivalence-15

     1. Status of URIEquivalence-15. Relation to
        Character Model of the Web (chapter 4)? See text
        from TimBL on URI canonicalization and email from
        Martin in particular. See more comments from
        Martin.
          1. What should a finding look like for this?

    [Ian]
           TB: Martin has made a kind of overwhelming
           case that we are stuck with char-by-char
           equivalence. We should say "When composing
           URIs, don't use percent-encoding unless you
           have to, and use lower case when you do."
           DC: If you mean the same thing, spell it the
           same way. Someone may use e and E differently,
           so you'd better have good information before
           considering them to be equivalent.
           TB: the cost seems to be too high for
           considering %7e and 7%E to be different (see
           MD's arguments).
           DC: The cost of having receivers convert
           things is astronomical. It's easy for us, on
           the other hand, to say "use lower case when
           you percent-escape."

    [ChrisL]
           (2) is always needed in HTTP, no?

    [Ian]
           DC: If you write href="~...", the client
           better put a "~" byte on the wire, and not a
           %7e

    [ChrisL]
           once it goes over the wire?

    [Ian]
           TB: Regardless of this, I think we can easily
           achieve consensus that it's worthwhile to make
           this point in the arch document. And make the
           point that for max interoperability, don't
           %-escape unless you have to, and use lowercase
           when you do.
           DC: If someone gives you a URI, don't screw
           with it.
           TB: Maybe not true: If a user types in a URI
           that has a space, then you are required to %20
           that.
           DC: But in that case, the user didn't give a
           URI.
           TB: Right - if given a URI, don't scree with
           it. if composing a URI, there are cases where
           must escape things, others where shouldn't,
           and if given a percent-escape, don't screw
           with.
           CL: You percent-escape Kanji as late as
           possible.
           DC: Spaces and Kanji characters -are they in
           scope here?
           CL: I'm happy to co-write a finding with
           Martin.
           RF: The href attribute is CDATA (or whatever).

    [ChrisL]
           anyURI

    [Ian]
           RF: The attribute value has to be translated
           from xml entities to something that looks like
           a URI. If there's a space into it, it needs to
           be translated into a URI first.
           DC: Test case: two documents fed to an xslt
           processor. One has space, the other %20. The
           namespaces spec says that these are URi
           references. One guy spells the namespace name
           with 7-bits, the other with more.
           RF: Mozilla treats space as illegal char. IE
           treats as auto-conversion to %20 (for href's
           in general). IE sends out the space over the
           wire.

    [TimBL]
           I have a feeling that there will probably some
           situation where the TAG has to say: stop, do
           it differently.

    [Ian]
           TBL: What's the next step? Continue from here?
           Or have someone go off and work on it?

    [DanC]
           my test case is from a question of
           interpretation sent to the XML Core wg (via
           xml-names-editor or xml-editor or some such).

    [TimBL]
           Maybe we need a set of test cases.

    [DanC]
           (I'm not sure about my "if you mean the same
           thing, say it the same way" position, now that
           we get into the IRI territory)

    [Ian]
           CL: I'd like to see whether the "character
           model of the web" says this.
           TBL: Please keep this on agenda for next time.

   2.4 Postponed

     1. Status of discussions with WSA WG about
        SOAP/WSDL/GET/Query strings?
           + ACTION DO 2002/06/24: Contact WSDL WG about
             this issue (bindings, query strings and
             schemas) to ensure that it's on their radar.
             See discussions from 24 Jun TAG teleconf.
     2. xlinkScope-23
          1. Priority of this?
     3. augmentedInfoset-22:
           + Request from Tim Bray to decide this issue
             (disposition = closed). Pushback from Simon
             St. Laurent.
           + ACTION DC 2002/06/17: Talk to XML Schema WG
             about PSVI. Report to tag, who expects to
             decide whether to add as an issue next week.
             DanC has sent email; awaiting reply from XML
             Scheme WG.
     4. deepLinking-25
          1. Action PC 2002/07/22: Ask Henrik Frystyk
             Nielsen to provide us with a precis of the
             ruling. Done: awaiting reply from Henrik.
     5. uriMediaType-9: Status of negotiation with IETF?
        See message from DanC.
           + Action TBL: Get a reply from the IETF on the
             TAG finding.
      ________________________________________________


     Ian Jacobs, for TimBL
     Last modified: $Date: 2002/07/30 12:33:47 $
Received on Tuesday, 30 July 2002 09:10:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:10 GMT