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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Images embedded in XML

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