i hit a complexity wall
now that i'm finalizing support for media types and adding nominal support for Atom as a media type, i am hitting a 'complexity wall.' and that's an indication i need to make a major shift in how a approach/solve a problem.
my initial design involves using XSL/XSD as a way to handle text streams for both request and response. i even convert sql data into xml when i read it and convert 'form-encoded' data to xml when i receive it from a client browser. this creates a single format for doing validation and for transform it for storage (xml->t-sql sprocs, atom->plain-text files, etc.) and for reading in data. nice. clean. simple.
except the last item. it's not so simple any more. i added support for using XSLT for request and response transformations. then i added support for using XSLT for variations on a method GET-item vs. GET-list; POST vs. PUT, etc.). then i added support for using XSLT for variations in media types (Atom, POX, RSS, etc.). and, after just a few rounds, i realized that i could use a default fallback for various types (once you have an Atom XSD that works, you don't need it for each resource definition, etc.). now you see where it's going, right?
(method + variant(item|list) + request|response + media-type) * (local-file|default-file) = document-to-use
right now this is done by testing scenarios in a standard order until i get to one that exists. it's all getting too messy. i need a new strategy.
this is fun, really.