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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Why XML for Messaging?

[ Lists Home | Date Index | Thread Index ]

----- Original Message ----- 
From: "Bullard, Claude L (Len)" <len.bullard@intergraph.com>
To: "'XML Developers List'" <xml-dev@lists.xml.org>
Sent: Wednesday, June 08, 2005 5:30 AM
Subject: RE: [xml-dev] Why XML for Messaging?

> If you dig through the original DTDs for what has
> now become X3D, you'll find the very first one
> was mostly just geometry because that made
> sense.  It has my name on it.  It started the
> process but was quickly tossed away.
ok, that makes sense.

I am arguing, not because I think it is actually useless, but I believe it 
does have a number of problems.

but, what I still do feel is needed is, a well defined format for a well 
defined task. not some big mass of "components", with no real distinction 
between the structure and semantics of the data.

sorry again if I am missing the point...

> The problem was X3D had to be upwardly
> compatible with VRML97 and it was patterned on HTML.
> So they poured it all into one bucket because
> HTML was predicated on the notion of one
> neatly and possibly compressed file.  Designs
> for games and designs for internet apps differed
> in that respect, at least in theory, because
> packets are cheaper than connections.
yes, however, it does seem like a bit of a mess imo.

ok, so, yes, games do end up with a very large number of very specialized 
files. one could vary this, but, they could have at least kept a game-like 
design internally?...

> Spilt milk.  X3D works well enough for this
> pass.  The critical thing is to keep the
> standards moving forward so that the technology
> does not get captured by private interests.
yes, ok.

I guess a bigger challenge for X3D is it's rarity/lack of app support? (a 
quick skim shows that pretty much none of my apps seem to support it).

though, maybe it aims for something different though?...

if it's intended use is 3d windows in web browsers, then, yes, maybe a 
single specialized set of tools for accessing it makes sense. however, the 
whole "3d in a browser" thing does not make that much sense to me unless the 
browser can be competitive with that of a game engine, or what could be done 
with a special purpose tool for some other format.

maybe I am missing the point, but I am not clear if there is that much of a 
point for it (at least for the time being). it does not seem to be well 
posed as a "uniform format for application data interchange", and it does 
not seem like a worthwhile format for simulating 3d worlds either.

all I can come up with is "format for users to look at 3d animated gizmos", 
ok, not so compelling. 3d animated gizmos, maybe better than pictures, but 
actually worth it?...

unifying 3d model formats seems like a good goal, eg, if I could export from 
one app and load in another, with a common format, that would be quite 
useful (vs, say, a large number of apps, each supporting a lot of formats, 
but maybe only at most having 1 or 2 in common). I have read some about some 
different efforts to face this problem.

shared 3d worlds, could be quite interesting, but then again, I would 
personally imagine it being approached "differently".

actually, I once beat together a trivial 3d client for jabber/xmpp, which I 
had felt could possibly be interesting. the problem then became the 
bandwidth limits enforced by the servers. really, it was difficult to stay 
below the limit. appart from this, it could have been interesting, but I had 
personally lost interest (shortly after beating together the app).

"best" would probably be something resembling a game server, eg, with users 
interacting with it through use of udp packets (or maybe tcp streams, 
possibly worse, possibly better).

my attempt avoided a game server, but paid for it (eg: only being able to 
send an update every few seconds to keep the server from noticing). I didn't 
have any 3d worlds or anything, but could have. in my case, I was going over 
multi-user chat, so the thing could have been, eg, having a client set up as 
a "world bot", which would go about managing world related stuff, and 
telling users what map is being used, ...

things like maps could reside on websites, and be pulled down as needed (a 
simple idea would be bundling a lot of the related files, eg, in zips).

how would this relate to x3d? ideally, it shouldn't exactly, the format 
should not care about this. of course, this kind of thing is necessary in 
the definition of a shared 3d world.

now, for file formats, something "like x3d" could be cool, but, I don't feel 
the design is up to it. more likely, I would rather adopt file formats from 
the gaming industry...

> There are many rounds in social games that matter.
> BTW:  XML is awkward for graphics in several
> ways.  It's another 'suboptimum but ok' format.

xml, I don't think, is the main problem. I think the problem is more that of 
an "ass-backwards" design (but, then again, I am not sure exactly what it is 
trying to pull off).

note: I also dislike the 'X' model format, but, imo, it makes more sense...
'X' is a complicated format for a well defined task.

X3D is a complicated for a task I have yet to determine exactly.

the set of formats I end up using:
raw triangle meshes (many different uses);
ac3d, makes sense for static models;
smd, for skeletal models (characters, ...);
variations of the quake map format (in particular, valve 220).

any of these could probably be done well enough in xml, I don't doubt this.

just, by convention, these tend to be raw text formats. I don't feel xml is, 
inheritly, a worse representation than plain text. just, efficiently parsing 
it could be a little more work.

in particular, one important difference that comes to mind is memory use, 
with a line-driven text format, one can get by using a small amount of 
buffers, and only having a small part o the file in memory at once (the 
parsed form quite possibly being the internal representation), wheras xml 
would tend to produce large parse trees (eg: what is 10MB in line-driven 
text could be 10-15MB in xml could, depending on the parser implementation, 
take several hundred MB of heap to store the parse trees).

on this ground though, one can doubt the usefulness of xml for models, but 
it can still be reasonable though (one thing that comes to mind is 
intermixing the parsing and the processing to keep memory use low, rather 
than attempting to parse the whole file at once).

as a plus, xml provides an abstract representation, where extensions can be 
added without breaking existing processors (even if, for example, the app 
does not recognize some data, it can be ignored and the model still used). 
more so, I can imagine some possibly quite interesting advantages.

> len
> From: cr88192 [mailto:cr88192@hotmail.com]
> I have looked at X3D before, but had not been impressed in that it seems.
> it seems to have too much stuff embedded in itself, and tries to be too 
> many
> different pieces at once (rather than a number of different formats and
> files, each representing a different piece).
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>


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

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