L
Lew
BGB said: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 useto
guarantee correctness of the XML and guide processing. If you develop it /ad
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?
Huh?
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
arbitrary restrictions).
Huh?
XML is a formal specification for structured documents that is devoid of
semantics.
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
or XML+LZMA.
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).
Huh?
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
relevant.
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. Thanks
for finally making that clear. XML would be just fine as a transmission protocol for such a thing. I'm not saying ideal, but just fine.
If you're talking about network protocols you certainly are not talking about
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.
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, JAXB,
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.
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, ...
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.