[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Images embedded in XML

  • From: "Al B. Snell" <alaric@a...>
  • To: Danny Ayers <danny@p...>
  • Date: Sun, 08 Apr 2001 12:36:24 +0100 (BST)

docbook embedded images
On Sun, 8 Apr 2001, Danny Ayers wrote:

> I'll happily agree with you that XML does seem to have been a real success
> in documentation.

I <heart /> DocBook :-)

> I can't deny also that you could put together a
> self-describing binary format as you suggest. I would suggest that for such
> a format to be really useful, a tree-based model would be preferable to
> flat/relational model.

Yep. Although many people will assume that something SQL-able would be a
good idea, I've had enough trouble trying to adapt SQL to complex data
models to know the problems of that.

> You will need to convert between the serialized form
> and other forms (e.g. an in-memory tree), which if the format is not to be
> too rigid would in effect be a kind of parsing - though admittedly you could
> do it n times fasting than e.g. SAX. Ok, so if you put all this together,
> what would you be gaining? Say an order or two of magnitude of speed?  (and
> the same kind of gains for data storage) What would you be losing?
> Human-readability - I for one wouldn't lose any sleep over that.

It'd be pretty trivial to make XDF<->text converters that'd be very
portable (and so easily available) if developers need to peek isnide for
debugging, or hand-edit stuff for testing.

> Compatibility with visual representation systems (XML/XSL/XSLT/XHTML etc.) -
> this is hugely useful for a not inconsiderable range of applications, but
> could be replaced by a standard set of conversion tools XML <-> XDF. A huge
> range of interfaces & systems...but we could live with that.

If it's designed to be data-model-compatible with XML, especially if it
parses Schemas to get all sorts of type information, then there would only
need to be a single tool for each direction; and SAX parsers / unparsers
could handle XDF transparently without needing to change the application.

I've relatively few objections with the data model of XML. I mean, I'd
ditch the attributes in favour of just putting them inside child elements
(but I'm sure this argument has been had before), but there's an
increasing number of XML-based specifications out there that XDF could
just "inherit" without any extra work.

XML converted to XDF in this manner would have all leaf nodes as
type "string", so would not take advantage of efficient representations of
numbers, and would preserve all whitespace and comments so it wouldn't be
as efficient when used as a drop-in replacement, but as it got accepted
applications could start using the extended SAX/DOM features that would be
provided to interface with integer/date/float leaf nodes, actual
in-place "includes" rather than external enetity references that have to
be declared at the top of the document (which annoys me when splitting a
large DocBook document into seperate files... so I have my makefile run
the source document through M4 to build the actual XML for
processing; proper preprocessor much nicer than entities :-)

> So why not? One big reason - there isn't a commonly accepted standard. Ok,
> XML has major faults, SOAP is downright ugly etc. etc. but at least XML is
> spoken everywhere. A standard that can be built on top of and worked around.
> We can solve the real-world problems, ok in a sub-optimal way, but surely
> that's all we really need. Do we want systems that will be 1000x more
> efficient tomorrow, or ones that may be slow and clunky but actually work
> with each other *today*?

I reckon it could be done as a seamless upgrade path, though :-)

If the W3C aren't interested, then when I'm done on my current RFC-writing
project I'll make an RFC for it and see if I can get it accepted!

> Maybe a binary format will come along and be accepted worldwide - but given
> the current climate I think it's highly unlikely in the near future. I think
> we'll be looking at XML & kludges for some time to come.

This pains me, for I've been having to work with the kludges :'-(

> Danny Ayers
> http://www.isacat.net


                               Alaric B. Snell
 http://www.alaric-snell.com/  http://RFC.net/  http://www.warhead.org.uk/
   Any sufficiently advanced technology can be emulated in software  


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.