Fwd: Re: more thoughts about show=embed...

>X-Sender: elm@abnaki.East.Sun.Com
>X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
>Date: Wed, 23 Feb 2000 13:13:29 -0500
>To: Steve DeRose <Steven_DeRose@brown.edu>
>From: "Eve L. Maler" <elm@East.Sun.COM>
>Subject: Re: more thoughts about show=embed...
>Cc: Erik Wilde <netdret@dret.net>, "Eve L. Maler" <elm@East.Sun.COM>,
>         dorchard@ca.ibm.com, bent@exemplary.net,
>         David Lowe <dbl@eng.uts.edu.au>
>
>Argh.  If the starting resource were a single node, I would want the 
>entire location set described by the ending resource to be embedded in 
>that one place.  I'd be surprised at the results if the embedding behavior 
>changed when the starting resource become a whole set of locations itself.
>
>Also, while the pairwise correspondence makes logical sense, what about 
>when the number of locations doesn't match up?
>
>         Eve
>
>At 11:18 AM 2/14/00 -0800, Steve DeRose wrote:
>>on multiple returns...
>>
>>I don't think there's much to delve into; HyTime has a specific construct
>>for this, which uses about the only semantics I can think of that makes
>>sense: if two ends of a link are multiple ("multlocs"), then they
>>correspond pairwise. There are built-in notions of multiples, vs.
>>aggregates (where the set returned is intended to be coalesced).
>>
>>Since we do allow multiple, it seems we ought to at least say what we mean,
>>and the only thing I can think of is to either say they're always
>>coalesced, always pairwise, or you get a setting. I'd say we should make it
>>pairwise, and think about adding the option in a later rev.
>>
>>Eds, since we haven't said anything about this semantics, it seems like we
>>should. Thoughts?
>>
>>
>>Steven_DeRose@Brown.edu; http://www.stg.brown.edu/~sjd
>>Chief Scientist, Scholarly Technology Group, and
>>    Adjunct Associate Professor, Brown University
>
>--
>Eve Maler            Sun Microsystems
>elm @ east.sun.com    +1 781 442 3190

--
Eve Maler            Sun Microsystems
elm @ east.sun.com    +1 781 442 3190

Received on Wednesday, 23 February 2000 14:58:18 UTC