Lightly-edited IRC log of TAG Sep 16 telecon

<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> 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 

<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 
<timmit> <- 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 

<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 

<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 

<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> 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 
<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 
<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 
<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 

<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 
<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
<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 
<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


Received on Monday, 16 September 2002 18:31:09 UTC