Re: Link-3: Sets, Singletons, and Determinism

At 6:02 PM -0500 5/23/97, Michael Sperberg-McQueen wrote:
>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]
>>
>>I'm with David on this one:  links connect resources, those resources
>>are identified by locators.  Vanilla locators identify a single point
>>in a document.  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.

I was arguiing that span can _only_ be a last term in an address, because
there is not a reasonable definition of what is included in it for urther
addressing steps. The notion of "return" implies that some kind of
well-formed singlular item is at issue -- an in this case the iterm is a
pair of tree locations.
>
>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)"?
>
>How we answer that question determines whether the span makes any
>sense or not, and needs to be forbidden or not.

Yes, this is a real problem, but I chose to ignore th issue of whether
endpoints are inclusive or exclsive until I had made my point about their
relevance.

For my money, ID(a) should address the whole element, and make the above
span illegal. The only way sensible wqay to address a point is to pick a
spot in PCDATA, or an empty tag. OTherwise, you can address the start of an
element, but not its end, which seems both confusing (the comon case of
referring to a paragraph should not start referring to its start tag), and
incomplete (there's no way to refer to the end tag, even if you take that
point of view.

>Processing doesn't seem to me to have anything to do with it:  if I
>say
>
>    Each term in the location ladder returns a result, which may or
>    may not depend on the results returned by previous terms in the
>    location ladder"

SPANS should be ends of chains only. That's why I said they should not be
LOCSRCs. Sorry for lapsing into HyTime-ism. I don't think a span should be
a well-formed LOCSRC -- Eliot pointed out 3 definitions, all reasonable,
and inherently incompatible, and that's too many in my book.

>in what way is that more 'processing oriented' than if I say
>
>    Each term in the location ladder identifies a point, which may
>    or may not depend on the points identified by previous terms in
>    the location ladder"

If Spans can't be LOCSRC, the return issue would only be an API issue. And
that API issue was the problem that Peter was raising at the start of the
thread.

>I'm not talking about returning a byte string to the application;
>I'm talking about returning an intermediate or final result to
>whatever process is controlling the stepwise progressing through
>the rungs of the location ladder.  I.e. neither when I talk about
>identifying points nor when I talk about returning results am I
>talking about processing.

Just don't try to climb on spans and this problem goes away.

>Sheesh.

I'm sorry I wasn't clear. I intended to moot that point at the beginning,
at which point only API (processing) issues are left.


  -- David

_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Sunday, 25 May 1997 12:23:24 UTC