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.

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.

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.
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.
Never understood the RDF way of using # to mean "not za fragment identifier"
DC: There are namespace names.
People do indeed use URI to refer to things other than web pages.
TBL: If it doesn't affect the software, it's irrelevant philosophy.
No, the *definition* of dc.title has that length
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?
"aren't fragment identifiers"???
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).
really? there are ways to refer to 7 seconds into a video? I've been waiting for those, but haven't seen them.
[yet somehow, magically, calling it a "Document" precludes cars. Pls pick one side of your mouth to speak out of, timbl]
TBL: Ambiguity about owner's intent of what is identified.
WebCGM fragment syntax http://www.w3.org/TR/REC-WebCGM/REC-03-CGM-IC.html
DC: What if it's ambiguous but two things identified are identical?
SVG fragment identifiers http://www.w3.org/TR/SVG/linking.html#SVGFragmentIdentifiers
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.
RF: You can do this with RDF.
what Roy said
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).
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.
my car is on the web.
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.
I propose that Tim's definition of "document" is any bag of bits
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.
If timbl really means that roy could s/resource/document/g, it's much cheaper for timbl to s/document/resource/g.
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.
so they identify a search engine
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.html
RF: When you access a wais resource through a proxy, you are saying - give me a representation of this resource through wais.
timbl:Document = cyc:ConceptualWork, I think.
(this is the general gatewaying problem, which was established at Cern)
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?
(sounds like "do we assume all assertions are true")
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.

given any identifier, I can make a webpage out of it
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.
x [ is fff of x ]
x -> [ is fff of x ] mapiing woul dhave to be introdde between 2 incompatible webs
or <xml:lang="sp">si</> ?
<foo xml:lang="es">Si</foo> <!-- I suggest -->
(On the contrary it does mean that TimBL's stuff breaks when Roy's data is introduced)
then it is already too broken to use
DC: TimBL wants a guarantee that someone will never find a car at the other end.
it's not "I can't know that". TimBL's saying "I consider that false."
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?
isn't this an arcrole to say how much dereferencing is happening?
TBL: In general, there is an axiom that a URI identifies one thing in all cases.
I don't believe that axiom any more, btw, timbl.
TBL: If you use a URI in a relationship, it can indirectly refer to other things.
except in the trivial case - it identifies the resource that you get by dereferencing it
Chris, that's one (coherent) position: there are different ways to point. *p vs **p, in a sense.
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.
arcrole of "the organisation that published this page"
TB: I suggest we publish these logs and stand back and see what happens on www-tag.
as opposed to, say, arcrole of "the isp that hosts this page" or any other such arc role
In AaronSw's reply to TimBL (http://lists.w3.org/Archives/Public/www-tag/2002Jul/0319) I find much that I agree with.
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?
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."
(2) is always needed in HTTP, no?
DC: If you write href="~...", the client better put a "~" byte on the wire, and not a %7e
once it goes over the wire?
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).
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.
I have a feeling that there will probably some situation where the TAG has to say: stop, do it differently.
TBL: What's the next step? Continue from here? Or have someone go off and work on it?
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).
Maybe we need a set of test cases.
(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)
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?
  2. xlinkScope-23
    1. Priority of this?
  3. augmentedInfoset-22:
  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.

Ian Jacobs, for TimBL
Last modified: $Date: 2002/07/30 12:33:47 $