[
Lists Home |
Date Index |
Thread Index
]
----- Original Message -----
From: "cr88192" <cr88192@hotmail.com>
To: <xml-dev@lists.xml.org>
Sent: Thursday, November 18, 2004 11:12 AM
Subject: Re: [xml-dev] hello, new to list, thoughts
>
> ----- Original Message -----
> From: "Richard Bruin" <rbru03@esc.cam.ac.uk>
> To: <cr88192@hotmail.com>
> Cc: <xml-dev@lists.xml.org>
> Sent: Thursday, November 18, 2004 3:29 AM
> Subject: RE: [xml-dev] hello, new to list, thoughts
>
>
<snip>
> I went and looked.
> I will argue this on the grounds that binx is very different (in both
> design and goals).
>
> yes, it focuses on large datasets, however:
> in itself it is not really a format;
> it would not retain the ability to have "self descriptive" files;
> it itself is based on schemas, wheras mine does not use schemas;
> ..
>
ok, I was a little vague here, oh well.
binx is a format, but a format to describe a format and the format itself.
pardon if I am being a troll, I will just allow thoughts to wander some.
it is possible I might just disappear never to be seen again.
tacking schemas onto some data is not sufficient imo.
my dislike of schemas rests with their lack of ad-hoc flexibility.
everything has to be designed beforhand, and one doesn't have the ability to
as freely mix-match things, or just stick some other data into a file.
just like I dislike static typing, but am forced to live with it, and at
least can kludge around it if I feel (in c using my own memory
manager/garbage collector, a dynamic type system, ...). so what they aren't
part of the core language? really, an awkward dynamic type system is often
quite useful.
however, in a dynamically typed language the uses of static typing present
themselves sometimes. this does not, however, mean one should feel compelled
to try to code, eg, in languages like java in many cases...
many cool features seem to require, at least in some cases, the semantics of
static typing. however, the need for dynamic typing is similarly helpful.
just like class vs. prototype object systems. classes give one structure,
but prototype objects give flexibility (but with costs). I may need
something new here (a sort of hybrid...).
so what, my own prog lang?... yes, like some sort of weird
scheme/javascript/c hybrid (js style syntax, a lot of c style semantics on a
more scheme like typesystem...).
but then are the costs, the lingering pain of ffi being a notable one.
>
> mine still vague resembles it's heritige (riff), but that may be all but
> lost here. it most closely tries to mirror textual xml.
>
I had thought some, and had realized that almost ok would be xml with a
special parser/printer, base-85 data, and some amount of possibile
optimization info (eg: lengths of sub-branches and such).
however, what does it matter really? for data, one doesn't really need
interoperability or extensibility. these things are nice however, on is left
often left with the "oh hell, this isn't sufficient, guess I will have to
write my own crap" type situation.
this makes the "kludge additional data onto xml" approach look not very
compelling, may as well just make a custom format.
I personally have little real interest in "web-services", which tend to be
near the center of xml's domain.
I have had some interest in "distributed systems", but arguably of a
different sort, and efforts that lead nowhere eventually (pi and join
calculus, only particularly relevant within a suitable host language,
otherwise impractical).
most weight in things has been balanced twards things like web-services,
scientific computing, ... oh well.
xmpp was so cool imo. xmpp is general, and allows ad-hoc extension, and a
generally simple structure. this can be less said about other things using
xml, which imo often use things like namespaces, ... to the point of abuse,
and to me in many cases schemas look fairly overkill (crap, one is
presumably just beating together an app to work with the data, if something
is not right the app can just "do something sensible").
what does it really matter in many cases if the data is "valid", or even
really "sane" for that matter?
room is needed to allow kludging more crap on and hopefully avoiding
problems. here namespaces can be used to good effect. this is better than
more ugly kludges (eg: the typical special combination of flags and extra
data crammed, eg, in fields with typically other uses).
file formats offer at least a little less restriction. reading/writing data
can be done more procedurally (if the file format is abstracted to the level
of api calls, it matters less what is going on).
similarly, this can be used as a base for more "advanced" things, along with
simple "serialization of data" type features.
maybe it is just me, but when I thing "large amount of data" images, eg, of
video files or object stores more come to mind, more so than, eg, large
numeric arrays.
for all its coolness, xml is weak here.
riff, however, just falls too far short of my desires. even for simple store
images, I had to go beyond riff (an ugly kludge to allow either fourcc or
indexed string type id's). this was better, but still short.
yes, riff would make no sense for "web-services", I will not argue that.
riff is the base of such things as wav and avi. they show something, but
also how short things fall (why has riff not taken over file formats? imo it
is still too little for many things).
but, by beating against things, eventually I get an idea of why things are
as they are, and why my efforts are so ammazingly pointless.
what does any of this matter? I don't know.
I have just been stuck in a state where I am not really doing much else (and
some of the things I am doing might lead one to question my sanity, or
worse...).
oh well. the need to sleep presents itself...
|
