Some time ago, I watched a television show that linked the size of the US space shuttle's liquid booster rocket to the distance between two horses in a 2-horse cart.
My point is that technology is built on top of old technology, and XML is such an example. We have built so much on top of the XML now, and XML is built on top of ascii, that whether or not XML is the *best* solution for transporting data is not nearly as interesting as whether or not XML is the *best* solution for storing tree data for applications today. While the former is far from true, the latter is much closer to true. The same rounds of arguments constantly surround RDMS and whether a relational data structure is the best way to store data. And the answer is always the same: RDMS is *one* way to store data, and there are implementations that store this data very well, and there are APIs to these implementations in all major languages, and we find that using RDBMS is a very good way to address several problems in data storage: reliability, repeatability, ruggedness, transportability. And XML falls under the same arguments. XML is *a* technology, we all hate its verbose implementations at a low level, and in the end XML allows for some facilitation of certain tasks that makes XML very good to use. And when using XML, we have access to derivative technologies that make our lives even better. So is XML the best thing? Who cares, as long as with XML we are good enough, and we can build better solutions for our clients. Let's keep in mind that our clients neither care or know what XML's benefits or weaknesses are, nor should they be concerned by it. After all, as users of transportation, do we care why the braking system on a car or truck or train or plane uses a particular alloy over another? Of course not. It is simply a design problem for the company delivering a product. The same argument applies to XML. XML is an internal data storage device. We never, ever sell XML as a product on its own accord. It always requires a program to render/interpret it, and hence it is irrelevant to the final user as long as it does what the user wants. If the user wants interoperability of the data within multiple contexts, then we can address this with XML, or with another data storage construct. And if anyone here wants to roll their own, you can take my Perl XML module and replace the element container characters "<" and "/>" and replace them with "??" and "!!", and roll out your own tree-based markup... ;-). However, you will need to build your own parser since the SVG::Parser module sits on top of the XML parser of opportunity that the platform provided... (and the above paragraph shows what is great about XML: you can build your stuff on top of other peoples work, and there is less low-level effort required than when using other data packaging technologies) But we all know this anyways... so I am preaching to the choir here. /amen On Friday 09 December 2005 11:38, Mark Birbeck wrote: > Leonard, > > This is all true, but the key thing about XML is not its actual format > (i.e., angle brackets, quotes, attributes, elements, etc.) but its > *abstract* format. Take XQuery and XPath; with these languages you can > query any data that can be cajoled into 'looking like' a hierarchical XML > structure. It doesn't really have to live in a world of angle brackets, it > just has to be represented in a hierarchical manner. > > So there is no reason I couldn't use XPath to find the colour of the 53rd > pixel on the 22nd row: > > /screen/pixels/row[22]/pixel[53]/@colour > > Or something or other like that! Anyway, the point is that the underlying > data need not be stored in some memory-hungry, pointy-bracketed > structure--it can still be the very efficient manner used for screen > pixels. But the layer that provides access to the pixel (now a 'node' with > properties represented by 'attributes') could be an XML-family layer. This > provides a powerful layer of abstraction. > > The key thing is that XML and its related technologies have given us a > convenient set of *abstract* tools (for querying, traversing, creating, > etc.), as much as they have given us a convenient set of actual tools > (Xerces, MSXML, Libxml, etc.). > > I hope that's not too philosophical for this time of the day. ;) > > Regards, > > Mark > > PS A couple of years ago, Steven Pemberton gave a controversial > presentation at the XML Europe conference; in effect he argued that now we > had 'the structure' we no longer needed 'the scaffolding'. In other words, > XML as a concept helped us to get to the point where we had abstract query > languages, abstract DOMs and so on, but now we have the abstract languages, > we need concern ourselves less with the concrete form of the languages. For > example, why not 'parse' free text into a 'DOM' and then query it using > XPath? > > > Mark Birbeck > CEO > x-port.net Ltd. > > e: [EMAIL PROTECTED] > t: +44 (0) 20 7689 9232 > w: http://www.formsPlayer.com/ > > Download our XForms processor from > http://www.formsPlayer.com/ > > > -----Original Message----- > > From: [email protected] > > [mailto:[EMAIL PROTECTED] On Behalf Of Leonard Rosenthol > > Sent: 08 December 2005 23:14 > > To: [email protected] > > Subject: RE: [svg-developers] Why is being in XML better? > > (was Re: Adobe/Macromedia) > > > > > We like xml because it is The Great Panacea. What else do we need? > > > > > > > I agree that XML is a wonderful thing...I spend lots of > > time in XML myself (and have for almost 10 years now). > > > > I do not, however, consider it "the great panacea". > > There are many things for which it is NOT a good solution. > > > > For example: > > * It doesn't make a good RASTER IMAGE data format. (could you > > see a grammar with a value per pixel? ;) > > * It doesn't make a good packaging solution. (which is why > > ZIP is used in > > conjunction) > > > > > XML is kind of handy because of all the work that has been put into > > > working out the APIs to work with it. > > > Every language handles XML, and XML of some type is now the > > > lingua-franqua for data transfer. > > > > I agree that the APIs are wonderful and access from any > > language is great - but I can also use a screwdriver for a > > numerous purposes that it wasn't originally intended. > > > > My point is simple - use XML for what it was intended > > to be...human (and computer) readable structured data. Don't > > try to shoe horn everything into XML - it's not going to fit :(. > > > > > > Leonard > > > > > > > > ------------------------ Yahoo! Groups Sponsor > > --------------------~--> Most low income households are not > > online. Help bridge the digital divide today! > > http://us.click.yahoo.com/I258zB/QnQLAA/TtwFAA/1U_rlB/TM > > -------------------------------------------------------------- > > ------~-> > > > > ----- > > To unsubscribe send a message to: > > [EMAIL PROTECTED] > > -or- > > visit http://groups.yahoo.com/group/svg-developers and click > > "edit my membership" > > ---- > > Yahoo! Groups Links > > > > > > > > > > ----- > To unsubscribe send a message to: > [EMAIL PROTECTED] -or- > visit http://groups.yahoo.com/group/svg-developers and click "edit my > membership" ---- > > > > > SPONSORED LINKS > Computer internet security Computer internet business Computer internet > access Computer internet help How to format a computer hard drive How > to format a computer > > > YAHOO! GROUPS LINKS > > > Visit your group "svg-developers" on the web. > > To unsubscribe from this group, send an email to: > [EMAIL PROTECTED] > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. -- Ronan Oger Director RO IT Systems GmbH ...Building Web2.0 with SVG since 2001 http://www.roitsystems.com ------------------------ Yahoo! Groups Sponsor --------------------~--> Most low income households are not online. Help bridge the digital divide today! http://us.click.yahoo.com/I258zB/QnQLAA/TtwFAA/1U_rlB/TM --------------------------------------------------------------------~-> ----- To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ---- Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
