Michael said,
> OK, well, maintainability will matter eventually: if inheritance in
> the XML makes things so unreadable that nobody wants to
> maintain it, that's obviously bad. Who cares if it's easier to tack
> on a new device if you can't even debug the XML
> for the ones you have?
In my experience, extracting data from most XML is, like apprehending content from most HTML, not pleasant for your average human.
XML is really a machine to machine data format. The idea of people entering devices and data straight into the xml sounds silly to
me. It is highly error prone and painful, and xml is not forgiving. So, I would think there should be a component that generated
the XML, well-formed and correct, whenever it is requested or needed. But if that is the case, why not just push a java binary?
This pretty much eliminates the worry for an unreadable xml structure that nobody can maintain. Maintain the data in mysql or
jeeze, an csv flat file you can edit and read in Excel (yikes). Then publish as loadable java class (or xml).
"Yeah, but then the client has gotta use java."
Sure, but like...duh. No, really. I don't think simply publishing data is going to be *that* useful to anyone (subject already
discussed). What could be useful is a component that accepts a string, the user agent, and returns all the juicy data we want.
Say, even make it pluginable into something like a web server. That component has got to be fast. It has to parse the user agent,
look up the right device and return it all very fast (at least if this were to acutally be deployable in a web environment). Now if
this module was java, then there really may not be any need to use xml. You have a
1. developers database (java) where data is entered, modified, etc.
2. device lookup module that matches a user agent to a record in the above.
If both 1 and 2 are written in java and developed as part of the same project, XML is really not necessary. In fact it may be the
least efficient of other options. In fact, why not think of 2 as a super-duper light-weight highly optimized java database that has
an extendable API?
> There's always XSLT if it needs to be backed out to some
> flatter representation, isn't there?
Good point, but it seems to be the starting point needs to be a format that is a flexible data format to edit and change for
developers. Say you have your xml file with 150 devices and suddenly decide to add an element to each node, or change the name of
an attibute that affects every device. XML is hell for that. There is no way but to write a java or perl fixer or use an XSLT
tranformer. In which case, you might as well just start out will the "nice" format and transform to xml when you publish the data.
Christian
Received on Tue Feb 26 16:51:34 2002