I think the point of using XML would be to have a language-agnostic way of
representing the information - in this respect I wouldn't be as excited
about an all-Java implementation.
I happen to be a language polyglot myself, and although parsing things with
the DOM or SAX is not very simple, there are language specific tools to make
the job easier. For instance in Java the Jakarta project's Digester makes it
pretty easy to produce object structures from arbitrary XML. Or in Perl
XML::Simple is a nice easy way to get info from XML. Python and Ruby have
similar interfaces which are easier to use than the standard XML APIs.
The other advantage to XML is, the structure is editable by hand - I have
actually gone to the trouble before of encapsulating all my client profiles
in objects before, but the data actually becomes more opaque and harder to
edit and maintain that way, in my opinion. XML on the other hand is editable
by hand. Most applications that I can imagine could read the XML and produce
an object structure from that data, which would be maintained by the
application persistently in memory - in this case performance
characteristics of XML parsers is not so important, although many of them
are passably fast in this day and age.
As for the exact form of the XML, I think a nested format is hard to read
and is not really what's needed. I think it would be easier to read
something where maybe there was a tag that was part of a device descriptor
that said, "this is my parent device descriptor". There would then be a
hierarchy of device descriptors defined, but the structure of the file would
be flat, not a nested structure. Not complicated, is the key here, I think.
Even info about screen size and various content type support, keyed off of
User-Agent strings, would be of enormous use, I think, since this
information currently comes from various different sources and is compiled
separately on an as needed basis by many different individuals. The level of
detail provided in CCPP is an ideal to shoot for, but even something much
much simpler would be a help, in my opinion.
Brian Takashi Hooper
Jiqoo, Inc.
----- Original Message -----
From: "Christian Molstrom" <cmolstrom@lightsurf.com>
To: <keitai-l@appelsiini.net>
Sent: Tuesday, February 26, 2002 11:45 PM
Subject: (keitai-l) Re: open source keitai tools (was Re: Re: western phone,
imode si
>
> 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
>
>
>
> This mail was sent to address brian@jiqoo.com
> Need archives? How to unsubscribe? http://www.appelsiini.net/keitai-l/
>
>
Received on Tue Feb 26 18:11:02 2002