[
Lists Home |
Date Index |
Thread Index
]
> > > No way. Have you ever looked at a spec for a binary file format?
Most
> of
> > > the ones I've deal with have taken a few hours to bang out an
> > > implementation of (except TIFF; implementations of TIFF are never
> > > finished...)
> >
> > For you and me, yes. For the average business programmer? I
disagree.
> > We're talking about the kind of people who spend most of their day
in
> > Visual Basic.
>
> But THEY don't even want XML; they probably don't find wandering a DOM
> tree
> any more friendly than calling whatever passes for Perl's "pack" and
> "unpack"
> in VB. They are the people who want to just have magic serialisation
from
> data structures to strings of bytes.
Good point. There are products (like J2EE 1.4 from what I hear) that
provide OO serialization to/from XML for "free" though.
>
> > > No it's not... I've got quite a few custom protocols I put
together
> > > lurking around my systems.
> >
> > If it is running on YOUR SYSTEMS then it isn't deployed in the sense
I
> > mean. I'm asking have you ever tried to deploy a protocol that would
> > have dozens of independent implementations and thousands of users?
> > That's _really hard_ and many good protocols never make the leap.
>
> That's purely a problem of adoption in the protocol marketplace, not
> difficulty of development.
>
> But I'm a little WG right now developing a protocol to replace IMAP,
and I
> helped out a bit in developing the PNG image file format (which has
dozens
> of
> independent implementations and zillions of users). I wasn't there at
the
> beginning, but they did pretty much what I'd have done if I was (he
says,
> modestly).
>
> PNG is a nice example of a file format. It's extensible by third
parties
> to
> create their own specialist metadata that can just be ignored by
> applications
> that don't understand it. Better than XML, those extra chunks (sort of
> like
> tags) can be marked with metadata about how applications that don't
> understand them should handle them.
>
> 1) The chunk might be something like an indication that the image data
is
> compressed in some bizarre new way. In which case, it is marked so
that
> applications that don't understand it are forced to reject the file.
>
> 2) If not, the chunk still might be something like a thumbnail image
or a
> histogram of colours used in the image; if a processor changes the
image
> but
> doesn't understand this chunk it should remove it since it won't be up
to
> date if the image is changed
>
> 3) Finally, the chunk should just be ignored, and left untouched if
the
> image
> is altered. Stuff like copyright notices and so on.
That sounds like a rather wise thing to do. Any idea why the XML spec
doesn't include mechanisms for meta-model information?
> Just to reverse positions, I see XML as useful for marking up text...
but
> it's not well fitted for data. As far as I can tell there's been a
> conceptual
> bleed from:
>
> This is <emphasis>tasty</emphasis> cheese
>
> (taking a string of text then slipping a few tags in here and there to
add
> abstract style information)
>
> to:
>
> <document>
> <title>Alaric's Cheese Bible</title>
> <para>...</para>
> </document>
>
> (extending that to expressing metadata, but still expressing the
metadata
> in
> terms of abstract styles; remove all the tags and you get:
>
> Alaric's Cheese Bible
>
> ...paragraphs...
>
> <title> is really just an abstract style with a schema constraint
added
> that
> you can only have one, and as the first thing in a document).
>
> to:
>
> <cheese>
> <name>Cheddar</name>
> <colour>Yellowish</colour>
> <price currency="UKP" unit="kg">2.50</price>
> </cheese>
>
> ...without enough stopping to think if it's a good idea.
>
> I'm not even sure if the latter was what the W3C intended when coming
up
> with
> XML; the introduction at http://www.w3c.org/XML/ states that it was
> designed
> for publishing, not data transfer, but it's becoming used for data
> transfer
> anyway.
>
> Is this just people noticing that something should be used for more
than
> it
> was intended for (which I'm suspicious enough of :-), or is it people
> misapplying something out of foolish over optimism?
>
> Whose idea *was* it to use XML for data interchange? The W3C seems to
> disavow
> responsibility in the first paragraph of that introduction. But
somebody
> somehwere made a mental leap from "styling a human-readable document"
to
> "data transfer". There are gray areas between the two, since an
invoice
> might
> well be considered to need to be both a readable document and a piece
of
> data, but nobody seems to be putting <?xml-stylesheet?> PIs in their
XML
> purchase orders, do they?
>
> > > email,faveFoods
> > > "alaric@alaric-snell.com","Cheese"+"Yoghurt"+"Pizza"
> >
> > And what about recursive hiearchies? You can keep hacking the CSV
format
> > but eventually you'll reach a point of diminishing returns.
>
> Some might argue that XML is also being hacked to a point of
diminishing
> returns :-)
Some might. But some might argue that most C and Perl code is ugly.
|
