Re: [mmox] XML serialization

[Jon Watte <[e-mail]>]

Mark Lentczner wrote:
> Jon Watte wrote:
>> <map>
>> <value type="boolean" key="success>true</value>
>> <value type="string" 
>> key="something_i_like_to_eat_on_sundays">bananas</value>
>> </map>
>
> This format is notably more difficult for schemas (from XMLSchema to 
> RelaxNG) to support, since value now has a key attribute that is only 
> valid iff it is tested in a map element.  Second, you have left out 
> the top element, which needs to be something fixed, rather than being 
> map or array or value depending on the structure of the data.
>

Yes, my illustration was only an illustration of how to turn a tag-fest 
into something more useful.

> Including a type attribute also makes things difficult for schemas, as 
> the content of the value element now depends on the value of one of 
> it's attributes.
>

I don't think you can verify the content of any element absent the 
actual executable code endpoint. Trying to do that in schema is pretty 
useless IMO. For example, if we have a "float64_3" type for global 
position, then perhaps a schema validator could verify that the content 
of that element would be three float64 values separated by commas 
(assuming that's the defined serialization), but there would be no way 
for the schema to validate that that position was actually semantically 
valid within the target context, because that's a simulation property.

> Including the key value as an attribute value will make this somewhat 
> harder to edit in some systems where "human readable" text is 
> generally much easier to handle as element content.  Keeping the key 
> value as element content also keeps the processing with key values 
> consistent with the processing of string values with respect to string 
> handling including normalization.
>

My experience is the opposite. Hence, my proposed change :-)

Also, my suggested serialization is invariant to child node re-ordering. 
Most of the time, that's not important, but for some cases, where a tree 
might be put into a hash map for fast access, it matters. 
Not-order-specific XML is generally faster to parse and more robust, 
when you can actually assume it's non-order-specific.

I'd be comfortable with backing off to say that the element tag name is 
the data type, while key is still an attribute, but from my experience, 
putting the type as an attribute as well actually works out better in 
practice.

Sincerely,

jw