Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] additional thoughts (was: Re: hello, new to list, thoughts)
 ----- Original Message ----- From: "cr88192" <cr88192@h...> To: <xml-dev@l...> Sent: Thursday, November 18, 2004 11:12 AM Subject: Re: hello, new to list, thoughts > > ----- Original Message ----- > From: "Richard Bruin" <rbru03@e...> > To: <cr88192@h...> > Cc: <xml-dev@l...> > Sent: Thursday, November 18, 2004 3:29 AM > Subject: RE: 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... 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
