On 2/27/06, Antone Roundy <[EMAIL PROTECTED]> wrote:
Hmm. If I'm reading that right, I wouldn't want to organize my
websites that way.
Nor would I. I wouldn't advocate and actual directory structure as this, and instead a simple disection of the URI/IRI that would then be mapped to the proper Class/Method. In fact, in many cases you would simply be using this as a way to logically gain access to a returned set of XML for processing on the client. With this in mind, this could also, and more instinctively represent a specified XPath that simple used the preceding verb to determine the format of the returned XML (
e.g. embedding a sequenced set of instruction elements into the return XML expressing to the client what it would need to do to properly take the contained data set, process it, to then pass this to the proper process on the client for display, or for further processing. With this in mind, then yeah, youre right... the attributes could provide quite a bit of extended value that would never require a need to be sent to the server as the result would require the server to send the same attributes and values back to the client. Unless that information is required to insure that the infoset returned contains the correct data in which could only be determined by such attributes, then you're right... no need to send it for the sake of sending it.
And unless the specification for the "stylesheet"
link relation were to mandate that URIs be constructed in a way
enables readers to tell from the local path what type the stylesheet
is going to transform the feed to, you wouldn't have any way to know
whether you could apply such an interpretation in any given case.
Again, I agree, although with reservations. For those times in which an XML file is requested directly from the address bar of a browser such as to cause a refresh of the browsers state upon its return, then embedding the neccessary transformation file as a PI in the return XML infoset would allow this data to properly instantiate a transformation process. Of course, in cases such as this we've now abandoned our original Atom data feed for something completely different which means:
- We're well of topic
- This would be the improper list to discuss such situations.
I
don't really see the benefit of putting the information into the URI
versus creating an attribute whose sole purpose is to specify the
type. The number of bits it would save is trivial, and it would
require the extra step of parsing the URI's local path to pull
information out of it that could be taken more easily from a
dedicated attribute.
If this were to be the only point, then you're right... it would be pointless. But, at least the way I am currently thinking about using this scenario, the information contained in the URI/IRI is not to determine type, and instead to instantiate a process on the server that relates directly to the desired action for the server to take using the /verb/noun format, and as such return a specific set of instruction elements expressing a detailed list of instructions that the client should then perform to complete the requested task. While there are plenty more reasons than just this, one of primary benefits of using a system like this is that it brings into the equation the notion that the client would need to know very little to invoke a fairly complicated process. So, in essence, using the URI/IRI we could exprress to the server that we would like to send a message to a particular department or person within a company, and the result would not only contain a form to put your message into, but also the necessary information on how to go about sending this message (the proper URI/IRI, the proper format, etc...) as well as potentially a session-id-like key that would only allow for that unique ID to carry out a posted set of information to that particular person, and allow this to happen only one time. A new message would require a new request to the same URI/IRI. A system like this would easily allow for basic logic to be built in suggesting that any two requests from the same client in a specific period of time would be denied, the result bringing a stronger shield against spammers and the like.
Ultimatelly, (bringing this back to Atom) this type of URI/IRI usage could be coupled with subscribable programmability, in which our existing world of browsers would be enabled to perform a greater set of fairly complex tasks, the inititial client session could remain fairly thin, thus keeping things both fast and effiicient, would reduce server-load to simply return XML infosets in which no other information other than the URI/IRI would be required, therefore reducing server side CPU-cylces, and all of this could take place in a decentralized, subscription based world (via Atom data feeds, of course) which would mean that the software would ALWAYS be up-to-date (to ensure built in browser security measures are properly handled, the server would be required to keep the data feeds up to date from the various servers in which it subscribes to, but thats not exactly a heavy handed task, and would also ensure that these files could be scanned for potential problems using a combiation of virus software for enclosures, and XML Schema or other Scheman like technologies to ensure that rogue XML scripts could not be propogated. If one server can validate this information for a given set of clients, all of which can trust that this particular service has gone through the proper processinjg of this data before sending it to the client, then we save the client-side world from being required to do the same validation which, of course, would mean an extensive amount of processing would be saved by simpy putting this trust into a particular server node in which we know can be trusted.
Of course this is all theoretical at this stage, but it seems to me that there exists at least some potential somewhere in all of this... finding that potential, of course, is the key...
Thanks for your help and extemded information!
Antone
--
<M:D/>
M. David Peterson
http://www.xsltblog.com/
