OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Another try on groves

[ Lists Home | Date Index | Thread Index ]
  • From: Ken MacLeod <ken@bitsko.slc.ut.us>
  • To: Sean Mc Grath <digitome@iol.ie>
  • Date: 19 Sep 1999 10:04:15 -0500

Sean Mc Grath <digitome@iol.ie> writes:

> [Paul Prescod]
> [...]
> > A frame is not an "element", it has no "attributes". Now I claim
> >that a frame is an object and that it has properties. And any idiot
> >knows that objects can be represented in XML using a variety of
> >techniques but think about the logic of doing it this way: you are
> >taking a thing that is "logically" an object, expressing it in
> >terms of a text file format so that another module in the same
> >process can re-interpret it as logical objects.
> >
> >The *only good reason* to dumb something down into XML elements and
> >attributes is to move the information between processes separated
> >by space, time or incompatibility.
> 
> I believe it makes perfect sense to *think* of MPEGS, PDFs,
> whatever, in XML terms.
> 
> I't does not of course, make sense to *store* them as XML owing to
> the enormous size bloat. But who said the XML needs to physically
> exist in disk?
> 
> Case in point, I have written a SAX driver for the MySQL relational
> database. I have SAX software that can happily trundling through 1GB
> of records treating them as XML. The XML never physically exists but
> the entire API used to process the MySQL is SAX.
> 
> I can get programmers who have never seen MySQL, or its API, to
> write MySQL processing apps using a purely XML API. I do not see why
> the same cannot apply to other formats such as graphics, sound
> etc. In fact, I am working on a BMP driver right now.

To think of data in XML terms implies a translation that is (generally
speaking) non-obvious.  If it were obvious we wouldn't have so many
efforts trying to map XML to objects and vice-versa.  You can make *a*
translation that is easy to use, but it won't (yet) be a general
solution.  Correct me if I'm wrong, but that's probably the approach
(a [singular] translation) you used to map MySQL to SAX.

I believe many people would agree with the idea behind your point,
that a common API goes a long way to making communication and
programming tasks simpler.  That's what is being suggested with the
grove paradigm: a common API can be used that provides more direct
access to the underlying data, without requiring a semantic
translation to XML first.

-- 
  Ken MacLeod
  ken@bitsko.slc.ut.us

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS