Jürgen, that sounds a bit like you could model that type of resource as "redirect reference" [1], right?
Julian [1] <http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-02. html> -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: Pill, Juergen [mailto:[EMAIL PROTECTED] > Sent: Friday, March 28, 2003 11:52 AM > To: 'Slide Users Mailing List' > Subject: RE: properties and linknodes > > > Hello Wojtek, > > The Bind standard does not distinguish between the original > created resource > (url) and the next URL created via a BIND command. This means, that a > resource may be created with say "uri1" and a bind may attach say "uri2". > If the resource under "uri1" (better say the bind) is deleted, > only the bind > is deleted, the resource is keep and "uri2" will still point fully > functional to the resource. When "uri2" is deleted (better the bind) the > server is free the garbage collect the resource itself (content and > properties). > > The link object in Slide is a distinct resource. Currently we believe that > the link resource can not be used in implementing the BIND > standard. If this > would be true, the link object would be an extension of the Slide > API, which > could be used in the functionality you would require (link contains own > properties or they point to the properties of the resource, or the link > properties are the properties of the resource, excluding those properties > the link directly contains). > > Does this make sense? > > > Best regards, > > Juergen > > > > -----Original Message----- > From: nowe media [mailto:[EMAIL PROTECTED] > Sent: Freitag, 28. März 2003 09:17 > To: Slide Users Mailing List > Subject: Re: properties and linknodes > > I have found the RCF concerning DAV binding (LinkNodes). > > As they say: > > "A method submitted through one URI mapping, on success, MUST produce > the same results as the same method, with the same headers and entity > body, submitted through any other URI mapping to the same resource." > > Which means we should ALWAYS get the properties of the target node .... > > The problem goes back to the ordering of nodes, which I want to implement > the following way: > > 1. Set "order" attribute to each child node in a childer collection > 2. Retrieve all child nodes first and order them in memory using > the "order" > attirbute > > Here is the problem: > > When I am ordering a collection in which one element is a > LinkNode it makes > a difference wheather I get the "order" attribute of the LinkNode > or of the > target node. When I want to sort the collection and one of the "order" > attributes comes from a target node the whole sort process fails > and has no > sense at all. > > regards > > Wojtek > > > > > > > ----- Original Message ----- > From: "James Higginbotham" <[EMAIL PROTECTED]> > To: "Slide Users Mailing List" <[EMAIL PROTECTED]> > Sent: Thursday, March 27, 2003 8:14 PM > Subject: RE: properties and linknodes > > > > Don't know too much about the spec area in question, but from a > developer's POV.. If you get a resource and it's a link, then query the > props if you want the link props. Otherwise, resolve the link and get the > actual resource and its props. It will more than likely be based on the > context of your application. With that said, I hope that's how it > works such > that it is deterministic in how the properties are returned via the > respective APIs. Can't add there, just logically thinking this > out.. I need > to read the specs in more depth when time allows.. Easy 'nuff to check > though - search the RFCs. > > > > James > > > > > -----Original Message----- > > > From: Michael Plomer [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, March 27, 2003 1:09 PM > > > To: 'Slide Users Mailing List' > > > Subject: AW: properties and linknodes > > > > > > > > > Hi, > > > > > > that mainly depends on your application, doesn't it? > > > > > > In general, I'd say that if I retrieve a property (say, the creation > > > date) of > > > a link node, I'd like to know when the link was created, not > > > the target itself. > > > > > > Come to think of it, maybe it depends on the property you're > > > reading and your application. In the above example, the > > > creation date of the link may be of interest, but also the > > > creation date of the target. If, on the other hand, you want > > > to retrieve the content length, you sure want the length of > > > the target. At least I don't see a point in associating a > > > content length with a link node... > > > > > > Maybe you could provide more information on what you are > > > trying to achieve? > > > > > > Regards, > > > Michał > > > > > > >>-----Ursprüngliche Nachricht----- > > > >>Von: nowe media [mailto:[EMAIL PROTECTED] > > > >>Gesendet: Donnerstag, 27. März 2003 17:27 > > > >>An: Slide Users Mailing List > > > >>Betreff: properties and linknodes > > > >> > > > >> > > > >>Hi ! > > > >> > > > >>How should properties of link node be treated. > > > >>If I am retriveing a property from link node should I get the > > > >>properties of > > > >>the link or the properties of the link target ?? > > > >>Does any specification cover this subject ? > > > >> > > > >>regards > > > >> > > > >>Wojtek > > > >> > > > >> > > > >>------------------------------------------------------------ > > > --------- > > > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > > > >>For additional commands, e-mail: [EMAIL PROTECTED] > > > >> > > > >> > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
