Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: Interplatform (interprocess, interlanguage) communication Date: Thu, 9 Feb 2012 09:40:59 -0800 (PST) Organization: http://groups.google.com Lines: 227 Message-ID: <1178994.134.1328809259797.JavaMail.geo-discussion-forums@pbmw8> References: <26124274.18.1328738542263.JavaMail.geo-discussion-forums@pbks5> <4f332c0a$0$288$14726298@news.sunsite.dk> <2745507.3.1328760474286.JavaMail.geo-discussion-forums@pbcpo5> NNTP-Posting-Host: 173.164.137.214 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1328811890 27291 127.0.0.1 (9 Feb 2012 18:24:50 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 9 Feb 2012 18:24:50 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=173.164.137.214; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 X-Google-Web-Client: true Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:11882 BGB wrote: > Lew wrote: > > Arne Vajh=F8j wrote: > >> BGB wrote: > >>> as noted, many people neither use schemas nor any sort of schema > >>> validation. in many use-cases, schemas are overly constraining to the > >>> ability of using XML to represent free-form data, or using them > >>> otherwise would offer little particular advantage. > >> > >> xsd:any do provide some flexibility in schemas. > >> > >>> say, if one is using XML for compiler ASTs or similar (say, the XML i= s > >>> used to represent a just-parsed glob of source-code), do they really > >>> need any sort of schema? > >> > >> I would expect syntax trees to follow certain rules and not be free > >> form. > > > > In one breath we're singing the praises of binary formats, in the next = we > > complain that XML isn't sufficiently flexible. > > >=20 > it is not like one can't have both: XML is much easier to modify and maintain when flexibility is a requirement= . > have a format which is at the same time is a compressed binary format,=20 > and can also retain the full flexibility of representing free-form XML=20 > semantics, ideally without a major drop in compactness (this happens=20 > with WBXML, and IIRC should also happen with EXI about as soon as one=20 > starts encoding nodes which lie outside the schema). >=20 > this is partly why I was advocating a sort of pattern-building adaptive= =20 > format: it can build the functional analogue of a schema as it encodes=20 That rather defeats the purpose of having a schema. A schema is a contract that the various processes or other stakeholders use= to=20 guarantee correctness of the XML and guide processing. If you develop it /a= d=20 hoc/ you lose that contract. > the data, and likewise does not depend on a schema to properly decode=20 > the document. it is mostly a matter of having the format predict when it= =20 > doesn't need to specify tag and attribute names (it is otherwise similar= =20 > to a traditional data-compressor). I'm sure that's very clever, but it defeats the purpose of XML schema. > this is functionally similar to the sliding-window as used in deflate=20 > and LZMA (7zip) and similar (in contrast to codebook-based data=20 > compressors). functionally, it would have a little more in common with=20 > LZW+MTF than with LZ77 though. ... and now you're off on some weird tangential topic. > granted, potentially a binary format could incorporate both support for= =20 > schemas and the use of adaptive compression. >=20 >=20 > is XML really the text, or is it actually the structure? Huh? > I had operated under the premise that it was the data-structure (tags,=20 > attributes, namespaces, ...), which allows for pretty much anything=20 > which can faithfully encode the structure (without imposing too many=20 > arbitrary restrictions). Huh? XML is a formal specification for structured documents that is devoid of=20 semantics. > > "Do they really need any sort of schema?" with XML is usually a "yes". > > > > But only if you're interested in clear, unambiguous, readily-parsable a= nd > > maintainable XML document formats. > > >=20 > fair enough, I have mostly been using it "internally", and as noted, for= =20 > some of my file-formats, I had used a custom binary coded variant=20 > (roughly similar to WBXML, but generally more compact and supporting=20 > more features, such as namespaces and similar, which I had called SBXE).= =20 > it didn't make use of schemas, and worked by simply encoding the tag=20 > structure into the file, and using basic contextual modeling strategies. Bully. Good on ye. > it also compared favorably with XML+GZ in my tests (which IIRC was also= =20 > generally smaller than WBXML). remotely possible would also be XML+BZip2= =20 > or XML+LZMA. Compared "favorably" according to what criteria? > I had considered the possibility of a more "advanced" format (with more= =20 > advanced predictive modeling), but didn't bother (couldn't see much=20 > point at the time of trying to shave off more bytes at the time, as it=20 > was already working fairly well). Huh? > > People often excoriate the supposed verbosity of XML as though it were = the only > > criterion to measure utility. > > >=20 > well, a lot depends... >=20 > for disk files, really, who cares?... > for a link where a several kB message might only take maybe 250-500ms=20 > and is at typical "user-interaction" speeds (say, part of a generic "web= =20 > app"), likewise, who cares?... >=20 >=20 > it may matter a little more in a 3D interactive world where everything=20 > going on in the visible scene has to get through at a 10Hz or 24Hz=20 > clock-tick, and if the connection bogs down the user will be rather=20 > annoyed (as their game world has essentially stalled). And that's a use case for XML how, exactly? Saying "XML is bad because it doesn't keep bananas ripe" would be equally= =20 relevant. > one may have to make due with about 16-24kB/s (or maybe less) to better= =20 > ensure a good user experience (little is to say that the user has a=20 > perfect internet connection either). >=20 > so, some sort of compression may be needed in this case. > (yes, XML+GZ would probably be sufficient). Back in the universe where we're discussing XML's suitability, please. > if it were dial-up, probably no one would even consider using XML for=20 > the network protocol in a 3D game. Oh, you're talking about inter-node communication in a distributed game. Th= anks=20 for finally making that clear. XML would be just fine as a transmission pro= tocol for such a thing. I'm not saying ideal, but just fine. If you're talking about network protocols you certainly are not talking abo= ut=20 frame-by-frame transmission of data with reply at 10 Hz, no matter what the= =20 protocol, so your entire argument against XML for such a thing is moot. > > There is no inherent advantage of a LISP/list-like format over any othe= r, nor vice versa; it's all accordin'. If the convention is agreeable to al= l parties, > > it will work. If all projects were one-off and isolated from the larger= world, > > we'd never need to adhere to a standard. If we don't mind inventing our= own > > tools for anything, we'd never have to adopt a standard with extensive = tools > > support. > > >=20 > it is possible, it all depends. >=20 > a swaying factor in my last choice was the effort tradeoff of writing=20 > the code (because working with DOM is kind of a pain...). IIRC, I may=20 Huh? again. There's very little effort in writing XML code, whether DOM, JA= XB,=20 SAX or StAX, given the wide availability of libraries to do so. > have also been worrying about performance (mostly passing around lots of= =20 > numeric data as ASCII strings, ...). Based on what measurements? > but, I may eventually need to throw together a basic encoding scheme for= =20 > this case (a binary encoder for list-based data), that or just reuse an= =20 > existing data serializer of mine (mostly intended for generic data=20 > serialization, which supports lists). it lacks any sort of prediction or= =20 > context modeling though, and is used in my stuff mostly as a container=20 > format for bytecode for my VM and similar. >=20 >=20 > > Where are the *real* costs of a software system? > > >=20 > who knows?... Anyone who thinks about it realistically. > probably delivering the best reasonable user experience?... That's not a cost, that's a goal. > for a game: > reasonably good graphics; > reasonably good performance (ideally, consistently over 30fps); > hopefully good gameplay, plot, story, ... >=20 > well, that and "getting everything done" (this is the hard one). Those aren't costs. Those are goals. Clear conclusions require clear reasoning on actual facts with relevance. --=20 Lew