[mmox] XML serialization

[Catherine Pfeffer <[e-mail]>]

(Infinity: there is a question for you at the end of this message)

Jon said:
> A better way is
>
> <map>
>    <value type="boolean" key="success">true</value>
>    <value type="string"
>         key="something_i_like_to_eat_on_sundays">bananas</value>
> </map>
>
> natural way to express it.This has less of the angle bracket tax, and it
> has a VERY straight-forward parsing style. In fact, in my opinion it's
> the most In XPath, it's now trivial: "value[@key=success]"

Yes. I had thought at this solution too, but I had hesitated to propose it
straight away to the mailing list...

This solution has fewer angle bracket tax, but it also has hidden
implications. I assumed (perharps wrongly) that the authors of the XML
serialization had seen these implications, and rejected this solution
because of these implications.

Moving tags (<key>, <boolean>, <string> and so on) to attribute names or
values is not an innocent operation. Here are the consequences I can see:


1) To allow validation of the allowed types, the new "type" attribute would
need to be declared as an enumeration in the DTD or schema.

No big deal so far.


2) More of a problem: if using XML schema for validation, it is more
straightforward to check that
      <float>3.14</float>
and
      <integer>42</integer>
are correct, than to check that
      <value type="float">3.14</value>
      <value type="integer">42</value>
are correct.

(XML schema allows for checking that the data inside the tags conform to a
certain syntax, for example that floats are made of digts and possibly of a
decimal dot and a minus sign).


3) The key ("success" or "something_i_like_to_eat_on_sundays") is not part
of the data flow anymore, but part of the markup.

There are half-religious wars inside the XML world according to what should
be an attribute and what should be text ;-). Personally, in this case, I
would say that an attribute is more suited to this kind of data, because
then we could enumerate all the allowed values for the virtual world context
("name", "taper_x", "socks", "notecard_encoding", whatever is normalized on
top of VWSD), so I see this as an advantage of your solution.

On the other hand, if I understand well, LLSD has been defined to allow keys
to evolve rapidely and to be supported differently across various
implementations, so validating the key values is perharps a bad idea.


4) Other advantages of your solution, Jon: default values for attributes
could be omitted, and we could address size and signed-ness of the scalars
in separate attributes.

Examples:
         <value>42</value>
would be synonymous of
         <value type="integer" size="32" signed="yes">42</value>

         <value type="float" size="64">3.14159265353238</value>
would be synonymous of
         <value type="float" size="64" signed="yes">3.14159265353238</value>

Of course, there is a lot to spare on the angle bracket tax here, since most
data is probably integer, 32 bits,, and signed).

It is also more future-proof, since 'size="128"' could be added afterward
easily, even if not planned initially.


> I'm working on a list of the things I think are wrong with the current
> proposal, of which this is one thing (there are about six). If we're
> open to change on those things (including this), then I could get behind
> the LLSD. Stay tuned :-)

I have a similar list too ;-). Someone here has proposed a VWSD working
group to separate high level concerns (like meshes versus prims) from low
level concerns (like data types and serializations). If we are sure that
xxSD is the way to go (and not ASN or whatever), I would volunteer to be
part of such a group, and so would you, Jon, I guess ;-).

Infinity, how was the XML serialization thought? Have several alternatives
been compared and considered carefully? Or is it just the result of the
inspiration of the person who made it at a given time?

-- 
Cathy