Not sure where you got the idea that I'm validating. I'm actually loading a node to use for configuration information for a mock api (where the mock api has parameters which may or may not have non-null values). If the configurer chooses to specify a configuration for a specific company and location I want to pick that node when the api user provides a company and location as inputs. The node with no attributes would be the default configuration. I can certainly see that I could require that the nodes all have the same attributes with some specifying a "null" value, but I think the approach we've arrived at makes for a cleaner configuration file.
With a database I can say select where company="google" or I can say select where company="google" and location = "seattle" The column values can be nullable so I don't have to specify a value for each column in each row. Anyway, I'm happy with the solution, I mean no disrespect for E4X, and perhaps my usage is atypical. Thanks for the help! On Sat, May 29, 2010 at 11:04 AM, Oleg Sivokon <olegsivo...@gmail.com>wrote: > > > Well, normally you would know what parameters are required for the node to > have. So, you would just write an E4X for that specific set of requirements > and if the requirements change you would replace the entire block. Just as > you would replace CSS in HTML template. That is I kind of fail to see the > point in making validation dynamic and construct it at runtime instead of > hardcoding it. What I mean is, since you know that you have to look for > @company and @location attributes - why would you provide them dynamically > and try to construct a validating expression instead of having that > expression hardcoded? As per my experience the hardcoded validation always > works better... - less errors, easier to read code. Compare this to > constructing DTD or XSL dynamically - usually it kind of defeats the purpose > of having those tools :) > Well, I think this all comes from the inherent to XML lack of typing and > structure. It is usually to generic for the data it serializes. There are > different solutions for transferring data preserving typing and stucture, > which are also more compact and often times easier to use - AMF and Protobuf > would be the most popular probably. > >
