- From: Tim Bray <tbray@textuality.com>
- Date: Mon, 16 Sep 2002 15:31:14 -0700
- To: www-tag@w3.org
<TBray> Missing: Roy Fielding, Dan Connolly <TBray> Turning to agenda. Everyone OK? <TBray> Resolved to accept agenda <TBray> Resolved to accept minutes of Sep 9 <TBray> SW: Propose next meeting is Oct. 7 <TBray> ..so resolved <TBray> re F2F <TBray> SW: some votes on top issues in; SW has collated <TBray> other TAG members encouraged to vote <TBray> SW: I accept a deadline for Thursday to produce collated results of voting <Chris> my choice would be xlinkScope-23, contentPresentation-26 and formattingProperties-19 <TBray> DO: sailing trip 10AM-5PM, sandwiches on board, directions to follow <TBray> DO: bring wet-weather gear <TBray> DO: no backup plan for bad weather <TBray> DO: barbecue chez Orchard post-trip <timmit> I will be coming out on Monday alas - sounds like a great trip! <TBray> Also, gathering #2 Chez Bray/Wood Monday PM, details to follow <TBray> Completed actions: <TBray> PC is OK with the language regarding RFC process <TBray> CL reports completed action to see about HLink publishing; it's published <timmit> http://www.w3.org/TR/hlink/ <- CL action closed <TBray> CL reports completed action re soliciting wording from Martin -- it's in the charmod draft <TBray> Action: CL to post pointer to Martin's answer <TBray> deeplinking: TB action uncompleted <TBray> don't know about Dan's action, but prob not complete yet <TBray> (action on review of deep linking) <TBray> arch doc: 2 action items from Dan, outstanding ====================================================== <TBray> XLink-scope <TBray> CL: asked them to publish, and now it has been <TBray> CL: Steve posted some examples, some replies on TAG, seemed somewhat unconvinced <TBray> TB: so what could we do? XLink & HLink have similar semantics, different markup styles <TBray> TB: is either superior? Should XLink be deprecated? Is HLink appropriate? <TBray> DO: Maybe it's OK to have both... give guidance as to when a markup designer should choose one or another <TBray> CL: Seems to me HLink is a schema for linking <TBray> CL: In terms of verbosity, you'd need 10 of these things at the top, so maybe it's just moving verboosity around <TBray> CL: You don't need mmany attributes in xlink. Big difference is that XLink uses element as a link, HTML WG seems not to have really understood this <TBray> CL: In HTML linkiing is based on attributes, with some attributes sort of commenting on others, and HLink supports this, which might be valuable or might be not the XML way to do things <TBray> NW: HLink may be evidence that XLink is not suitable design for a large class of apps & XLink should be depracated <TBray> NW: I don't want to choose: I want one way to do things <TBray> CL Agrees <TBray> TBL: In general seems to be a good idea to be able to put information inline rather than in schema <TBray> TBL: so you won't be misled if you ignore the schema <TBray> TBL: We thought about the same thing in RDF... seems like people want to keep instance simple and put other stuff in the app or in the schema <TBray> TBL: What can you really expect of the commmunity? What pieces of SW are going to implement this? <TBray> TBL: You can justify HTML by saying there's an HLink schema... is this generalized <TBray> TBL: Little client software that's XLInk sensitive yet <TBray> CL: another aspect: what is the intended usage? Some say it's just HTML 'a', other images <TBray> CL: some say for any sort of thing that has a URI <TBray> CL is talking about XLink <TBray> CL but this applies to both... what is the intended usage? <TBray> TB: no doubt that XLInk is prejudiced toward browser-class applications <TBray> CL: some people said xlink would be more interesteing if used for everything <TBray> TB: My prejudice is for verbose obvious markup with subelements and no indirection <TBray> NW: agrees, but think XLink needs work, e.g. embed is not obvious at all to ordinary people <Norm> NW thinks it needs work if it's for anything other than human-readable hypertext markup <TBray> TB: however, there's no doubt that Steve's example is easier on the eye <TBray> SW: meta-question: is it in the scope of the TAG to deprecate things? <TBray> CL: it's premature to be killing XLink although we might end up doing that <TBray> TBL: whether or not it's in the remit, we can't do that, but we could certainly say we think something's harmful <TBray> TBL: if deprecation is to be done, w3c would have to implement some process to do this. <TBray> TBL: maybe the QA people should be involved <TBray> TBL: XLink makes sense if you look at it as being for UI languages, eg SVG & HTML <TBray> TBL: but it's dangerous to use it for everything that has a URI <TBray> TBL: so that idea is a mistake or a totally document-hypertext-centric worldview <TBray> TBL: we can't deprecate but we can point out what's dangerous <TBray> TB: dangerous to have 2 ways of doing things <Chris> http://www.w3.org/TR/SVG/attindex.html lists xlink usages of svg, fyi <TBray> TB: rddl is much better in RDF than XLink <TBray> TB: Strawman position: HTML's existing linking semmantics <a> <img> are well-established <TBray> TB: why do they need to be restated? <TBray> TB: if it is desired to extend HTML, why not do it with XLink? <TBray> SW: so what do we do? <TBray> CL: not quite true that HTML's existing semmantics are well-understood <TBray> CL: e.g. longdesc, nested <a>'s, and <img> not that well defined * Norm has written the code to "unwrap" nested A's and wonders if he doesn't know the good reason :-) <TBray> CL: these are all very user-oriented kinds of things <TBray> CL: but a link to a def'n of a term in a dictionary is not very interactive and might not require XLink <TBray> CL: but there are grey areas.... how about glyph? how about script? <timmit> q+ to ask whether HLINK is a compatible in concept with <TBray> TB: biggest difference between HLink & Xlink is XLink allows subleements to represent link ends, HLink is attribute-focused <TBray> TBL: is HLink a subset of Xlink functionality? <TBray> TB: er... in some part, HLink can do quite a bit. I (currently) think 'subset' is fair <TBray> PC: TBL is right that we can't deprecate <TBray> PC: no XQuery impact <TBray> Agreed: we will read HLink carefully and take up at the f2f ======================================================== <TBray> uriMediaType: action to DanC is ongoing <TBray> -------------------------------------------- <TBray> uriEquivalence <TBray> so, one action item outstanding for Dan to write up the assertion "don't screw with a URI someone gives you, just cojmpare it char-by-char" <TBray> another action item to CL to write reference to good practices into email summary ====================================================== <TBray> httpRange <TBray> TB: 2 worldviews: TBL says HTTP URIs necessarily refer to documents <TBray> TB: other worldview (esp Roy F): HTTP URIs can refer to anything <TBray> SW: how to move forward? <TBray> TBL: Roy refuses to consider RDF, says if there's a prob it's RDF's problem <TBray> TBL: this, and the view that a frag id identifies only a fragment, make RDF not work <TBray> CL: TBL says it can point to anything if it has a # in it <timmit> Chris: (IIUR) foo.rdf#bar ideentifies a bit of an rdf document. <timmit> Chris: (IIUR) foo.rdf#bar ideentifies a bit of a docuent. <TBray> scribe is unable to summarize this discussion <timmit> Chris: RDF understands a layer of dereference. <timmit> (That messes up language interop with URIs between different langauges) <timmit> TBray: I see 2 differen things. <timmit> ... TBL has asserted repeatedly htat the model that has HTTP [sans #] be not limited to documents makes RDF break. <timmit> .. could u explain again please? <timmit> ...Second thing: Passing on a 2nd argument by reference, Larry Massinter at the Seybold conference. <timmit> ... he said it was a wate of time to discuss what a reseoiurce was or wasn't. <timmit> ...If you can do it without answering that then it would b a big help. <TBray> TBL: need an axiom that an URI refers to the same thing in all circumstances <TBray> CL: linking from fooml to barml with a frag identifier gives a portion of a resource <TBray> CL: what you do with it depends on context <TBray> CL: if you link to a subpart of an RDF resource thn RDF has semantics about what that means <TBray> CL: SVG & HTML processors have semantics about what linking to a fragment means <TBray> TBL : where does the information come from <TBray> TBL: meaning of what an identifier identifies is only the URI string <TBray> CL: trying to move away from URI... once you deref you have a resource <TBray> CL: if you link into sub-part, you've linked to a part (with namespace context) then focus on what it means <TBray> TBL: question is, if RDF doc is serialized in XML, and #bar IDs an element which talks about a car, then RDF can say it identifies the car <TBray> TBL: what's to stop another language from using #bar to refer to apart of the XML serialization and start talking about chars in the elment rather than the wheels on teh car <TBray> TBL: you can do different things, but you can't identify something different <TBray> TBL: if you're consistent, then you can say http:....#bar is interesting and you understand what I'm talking about always <TBray> TBL if it can refer to different things then we've failed <TBray> NW: TBL, how do you reconcile that view with the rule that says the fragment ID has to be interpreted in context of resource's media type <Norm> http://nwalsh.com/test/xxx#foo <TBray> TBL: in RDF foo#bar can reference into things that actually don't exist <timmit> @@@@@ <TBray> TBL: when you publish something & you want people to use that to refer to something, you make sure that they get a consistent result <TBray> CL: you seem to be using the thing after the # as a means of subclassing URIs <TBray> TBL: in semweb, I'm using it as a hook to get into abstract space <TBray> SW: are there 2 separable issues here? <TBray> SW: TBL saying http uris have to be documents <TBray> CL: ?!?! <TBray> TBL: yes, it's an information object <TBray> TBL: it's not a car <TBray> TBL: because otherwise, you can argue forever as Larry M points out <TBray> TBL: we shd be able to agree on what an information object is, as in "not a car" <TBray> TBL: worried that Dublin Core writes a web page about concept of title & uses URI to refer to both the concept & the title <TBray> CL: confusing to change meaning just because there's a # <TBray> TBL: but it's a completely different thing, in RDF <TBray> CL: things were described with #'s long before RDF came along <TBray> TBL: HTTP doesn't talk about #, HTML & XML do <TBray> CL once you've fetched it, you go into part of it... <TBray> TBL: no, you instantiate that subclass of the object class <TBray> TB: where is support for class/subclass worldview in normative specs? <TBray> CL: if I refer to chap 1 of HTML spec, is this something different? <TBray> TBL: no, because HTML says what it means <TBray> TB: a bunch of stuff which I'll fillin by email <Chris> its a circular definition <TBray> TBL: chain of reasoning from URI spec to HTTP spec to HTML spec to say what a # means <TBray> TBL: RDF hijacks the # to bring a chain of reasoning to bear <TBray> TBL: the web architecture collapses in a heap if we don't have consistency on what a URI means <TBray> CL: can say a URI always defines the same resource by defining a resource as that to which a URi points <TBray> CL: we're familiar with resourcs which are immutable bits, and with things which are highly mutable e.g. weather forecasts <Chris> or even thegoogle "i feel lucky" link <TBray> CL: sometimes the definition helps, sometimes it doesn't help <TBray> TBL: another example... DubCore has a page that defines the title. <TBray> TBL; I'm talking about the card catalogue for moby dick <TBray> TBL: catalog was written by Jane yesterday, saying how long ago it was written etc <TBray> TBL if she can use the same URI for the card catalog card & moby dick the book, then... <TBray> TBL: in English we can wave hands & deal with ambiguity <TBray> TBL but if I query system as to when Moby Dick was written & the answer comes back "yesterday" becasue of card catalogue, then things break <TBray> CL: why is this limmited to the situation with URIs? general problem of linked lists <TBray> SW: what work do we have to do to bring issue to conclusion? I don't see the way forward. <TBray> TBL: I can't back down while there's no system that allows me to do rules for RDF inference about web documents. <TBray> TBL: can someone write up an answer to the example & show software working that allows me to query while distinguishing card catalog and date of book <TBray> SW: is it fair to ask TBL to pose the example? <TBray> TB: I think he has, with the card-catalog example <TBray> TB: will write some thoughts on card-catalog example Adjourned.
Received on Monday, 16 September 2002 18:31:09 UTC