Subject: [mmox] Automatic generation of the schema

From: Catherine Pfeffer <[email-masked]>
Date: Thu, 26 Feb 2009 13:10:49 +0100

Jon said:
> My question is not just to you, but to the list:
> We view the xxSD description language as a source language, from which
> we could compile various outputs.
> Could one of those outputs be a DTD and an XSD? Thus, we don't create
> the DTD or XSD directly; we create the mapping from xxSD input to DTD
> and XSD output.

I can't answer for the list, so I will answer for myself ;-) :

Yes, that should be possible. Infinity asked too if there would be a
mechanical way to map conceptual xxSD into the "XML way". I think the answer
is "yes", although it has more a chance to be a "compilation" from xxIDL to
XSD or DTD, than from binary xxSD. Or it could even take the form of a C++
library that would produce both the schema and the data. Not sure. That
would need to be investigated.

Currently, LLSD data flow mixes three things:
  - the data (102.5 meters);
  - the data type (float);
  - the field name (POSITION_X).

While this is acceptable in a binary stream, and provides an incredible
flexibility, it is most unusual in the XML world, and also wastes a lot of
bandwidth (compare 'i' to "<integer></integer>"). Okay, you can compress
with gzip, but then you both lose human readability and processor cycles.

In the XML world,
  - data (102.5 meters) appears in the data packets;
  - data type (integer) goes to the XSD schema;
  - the field name (POSITION_X) appears both in the data packets (but as a
tag, not as ordinary data), and in the XSD schema.

The advantage of separating the schema from the data is that you can send
the schema only once at the beginning of the communication of a viewer with
a given simulator. You don't need to repeat that the X position is a float
each time your avatar moves 10 centimeters to the left.

Of course, all these efforts make sense only if there is a real need for XML
stuff.

-- 
Cathy

---

From: Jon Watte <[email-masked]>
Date: Thu, 26 Feb 2009 10:53:09 -0800

Catherine Pfeffer wrote:
> Of course, all these efforts make sense only if there is a real need 
> for XML stuff.

I believe that for non-real-time, transaction-type requests, XML is the 
right choice. If I need to "get a description of the upcoming event X" 
then that's a very good mapping to existing web 2.0 standards, which 
want XML or JSON for the response. Whether the request is an XML encoded 
entity (a la XML-RPC and SOAP), or a url-encoded query string, may still 
be under debate. Personally, I'd prefer XML-RPC.

Similarly, for durable storage, I would prefer XML to binary, because it 
is much more likely to survive for longer, be more robust, and you can 
use standard tools when processing it off-line.

Sincerely,

jw