- From: Henry S. Thompson <ht@cogsci.ed.ac.uk>
- Date: Sat, 24 May 97 10:40:30 BST
- To: w3c-sgml-wg@w3.org
Michael says: > On Fri, 23 May 1997 04:59:08 -0400 (EDT) Henry S. Thompson said: > >[Discussions about sets of elements, and what xpointers 'return', etc. deleted] > > > >. . . Span locators identify a pair of points in a document. > >End of story. Nothing is returned. What applications do with a span > >is up to the semantics they implement for their link types. > > > >See how easy things are if we eliminate processing language [hint, hint :-] > > With respect, I think the problem here has nothing *at all* to do with > whether we use the verb "return" or not. > > In the document > > <a id='a'> > <b/><c id='c'>stuff</c><d/> > </a> > > what is the pair of 'point's identified by the span "ID(A)..ID(C)"? > > . . . > > Sheesh. Sorry to have pushed the wrong buttons. The aspect of 'returning' I was worried about was at the top level as it were -- i.e. the problems we get into in trying to speak about what 'the processor' passes to 'the application'. I THINK what my answer is is clear given the part of my comment I reproduce above, with the clarification that (modulo the pseudo-element question being discussed in another thread :-) by 'point' I mean (singular) resource, i.e. (grove) node designation. In the example to hand, that means a pair of nodes, one inside the other. Whether or not that makes sense is up to the application and the semantics it attributes to spans. I don't think it's our business to rule out a sensible semantics for such a pair a priori. I also don't think we should rule out "ID(C)..ID(A)" (inside-out) or backwards spans. Spans are just a suggestively named way of locating a pair of resources in a single locator. ht
Received on Saturday, 24 May 1997 05:40:34 UTC