Re: Interplatform (interprocess, interlanguage) communication
Arne Vajh=F8j 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=
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
In one breath we're singing the praises of binary formats, in the next =
complain that XML isn't sufficiently flexible.
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,
and can also retain the full flexibility of representing free-form XML
semantics, ideally without a major drop in compactness (this happens
with WBXML, and IIRC should also happen with EXI about as soon as one
starts encoding nodes which lie outside the schema).
this is partly why I was advocating a sort of pattern-building adaptive=
format: it can build the functional analogue of a schema as it encodes
That rather defeats the purpose of having a schema.
A schema is a contract that the various processes or other stakeholders use=
guarantee correctness of the XML and guide processing. If you develop it /a=
hoc/ you lose that contract.
the data, and likewise does not depend on a schema to properly decode
the document. it is mostly a matter of having the format predict when it=
doesn't need to specify tag and attribute names (it is otherwise similar=
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
and LZMA (7zip) and similar (in contrast to codebook-based data
compressors). functionally, it would have a little more in common with
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=
schemas and the use of adaptive compression.
is XML really the text, or is it actually the structure?
I had operated under the premise that it was the data-structure (tags,
attributes, namespaces, ...), which allows for pretty much anything
which can faithfully encode the structure (without imposing too many
XML is a formal specification for structured documents that is devoid of
"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=
maintainable XML document formats.
fair enough, I have mostly been using it "internally", and as noted, for=
some of my file-formats, I had used a custom binary coded variant
(roughly similar to WBXML, but generally more compact and supporting
more features, such as namespaces and similar, which I had called SBXE).=
it didn't make use of schemas, and worked by simply encoding the tag
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=
generally smaller than WBXML). remotely possible would also be XML+BZip2=
Compared "favorably" according to what criteria?
I had considered the possibility of a more "advanced" format (with more=
advanced predictive modeling), but didn't bother (couldn't see much
point at the time of trying to shave off more bytes at the time, as it
was already working fairly well).
People often excoriate the supposed verbosity of XML as though it were =
criterion to measure utility.
well, a lot depends...
for disk files, really, who cares?...
for a link where a several kB message might only take maybe 250-500ms
and is at typical "user-interaction" speeds (say, part of a generic "web=
app"), likewise, who cares?...
it may matter a little more in a 3D interactive world where everything
going on in the visible scene has to get through at a 10Hz or 24Hz
clock-tick, and if the connection bogs down the user will be rather
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=
one may have to make due with about 16-24kB/s (or maybe less) to better=
ensure a good user experience (little is to say that the user has a
perfect internet connection either).
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
the network protocol in a 3D game.
Oh, you're talking about inter-node communication in a distributed game. Th=
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=
frame-by-frame transmission of data with reply at 10 Hz, no matter what the=
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=
it will work. If all projects were one-off and isolated from the larger=
we'd never need to adhere to a standard. If we don't mind inventing our=
tools for anything, we'd never have to adopt a standard with extensive =
it is possible, it all depends.
a swaying factor in my last choice was the effort tradeoff of writing
the code (because working with DOM is kind of a pain...). IIRC, I may
Huh? again. There's very little effort in writing XML code, whether DOM, JA=
SAX or StAX, given the wide availability of libraries to do so.
have also been worrying about performance (mostly passing around lots of=
numeric data as ASCII strings, ...).
Based on what measurements?
but, I may eventually need to throw together a basic encoding scheme for=
this case (a binary encoder for list-based data), that or just reuse an=
existing data serializer of mine (mostly intended for generic data
serialization, which supports lists). it lacks any sort of prediction or=
context modeling though, and is used in my stuff mostly as a container
format for bytecode for my VM and similar.
Where are the *real* costs of a software system?
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, ...
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.