----- Original Message ----- From: "Kimbro Staken" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, January 11, 2002 8:48 AM Subject: Re: Problems With Implementing XMLDB API
> You're right in many cases that won't make sense, that doesn't have to be > the case though. The resource instance could easily know where it came > from and in theory could also know how to store it self back where it came > from when modified. It doesn't work that way right now and I don't know it > it should or not, but it would be consistent and would actually be very > powerful. > > > For this reason I suggest dissasociating the results of XPath queries from > > resources. > > > > What did you have in mind? Either a hierarchy of XPathResults objects or a single XPathResult type that has types information obtained from static types in an interface such as is done in the java.awt.Color or DOM classes. Apache Xalan actually uses both appraches http://xml.apache.org/xalan-j/apidocs/org/apache/xpath/objects/XObject.html The benefit of the hierarchy of objects is that objects of type XPathNodeSet and XPathTreeFragment can also implement the XMLResource interface and thus have the best of both worlds. A clear differentiation in the types returned by XPath queries while the ability to treat XML returned from XPath queries as resources is preserved. Thoughts? -- THINGS TO DO IF I BECOME AN EVIL OVERLORD #59 I will never build a sentient computer smarter than I am. > ---------------------------------------------------------------------- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---------------------------------------------------------------------- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ ----------------------------------------------------------------------
