Re: Why XML for Messaging?
----- Original Message ----- From: "Bullard, Claude L (Len)" <len.bullard@i...> To: "'XML Developers List'" <xml-dev@l...> Sent: Wednesday, June 08, 2005 5:30 AM Subject: RE: 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. > ok. 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@h...] > > 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> > >
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