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


Help: OASIS Mailing Lists Help | MarkMail Help



   additional thoughts (was: Re: [xml-dev] hello, new to list, thoughts)

[ 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

> 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 

oh well. the need to sleep presents itself...


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

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