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]
