Re: [mmox] XML serialization

["Meadhbh Hamrick (Infinity)" <[e-mail]>]

i stand corrected...

okay... John, Catherine and Jon...

can you create a proposal for a next generation XML serialization?

the existing serialization is in current use by SL, OpenSim and PyOGP,  
so there's probably going to be some resistance (from Linden) to  
changing something that currently works and is deployed and some  
people who have deployed OpenSim code (distinct from the people who  
created the code) MAY have some resistance.

which is to say... my co-workers will pummel with rotten vegetables if  
i commit them to supporting another serialization, despite it's  
obvious advantages. before making a change of this sort, we would be  
doing a fair amount of testing to ensure our system works fine with  
the new serialization. this would require a non-zero amount of  
resources be spent on deploying the change. ergo, we would need some  
justification for making the change.

that being said... "there are a number of deployed hosts with whom we  
want to interoperate who use this serialization" might be a suitable  
justification, or at least it would decrease the number of rotten  
vegetables i would be pelted with to an acceptably low level.

but may i ask? why do we need to change something that we know works,  
is already deployed, and seems to work without flaw?

my suspicion is that there's a belief that:
	1. there are too many angle brackets, leading to wasted bandwidth and  
wasted CPU use.
	2. it's hard to use with XSLT

so my response would be:
	1.a. can we look at the effect before making this change? my  
suspicion is that message sizes will be much more affected by turning  
on compressed content encoding than with the change from one DTD to  
another.
	1.b. do any of us have numbers about how much more efficient the  
"new" encoding is vs. the "legacy" encoding? sure.. there are fewer  
angle brackets, but really you're just trading parsing angle brackets  
for parsing attributes and enclosing quote.
	2.a. to a certain degree, the contents of the XML serialization are  
un-important compared to the contents of the object to which it  
deserializes.
	2.b. why is this more of an issue with XML map elements than it was  
when people were trying to use Apple plists with XSLT?

so... my recommendation might be...

* can someone write a "next generation" XML serialization proposal?
* can we do a bake off?
	* first with testing the space savings between the two serialization  
schemes after compressed content encoding is taken into account and
	* second with seeing how much of a decoding speed improvement you get  
from moving from keys in their own elements to keys as attributes.

-cheers,
-meadhbh

On Feb 23, 2009, at 2:18 PM, Hurliman, John wrote:

> Speaking as the maintainer of OpenSim's LLSD<->XML serialization  
> library (OpenMetaverse.StructuredData) I can say there would be zero  
> resistance from me in adopting a better serialization. In fact, I  
> would greet the changes with open arms, as would most people in the  
> open source virtual world sphere. Please do not put any of the  
> OpenSim/OpenMetaverse efforts in the same sentence when claiming  
> that improvements will be met with resistance. If there is going to  
> be a significant amount of resistance to anything that improves on  
> deployed and working Second Life technology, then I don't think this  
> will get very far.
>
> John
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On  
>> Behalf Of
>> Meadhbh Hamrick (Infinity)
>> Sent: Monday, February 23, 2009 1:47 PM
>> To: Jon Watte
>> Cc: [e-mail]
>> Subject: Re: [mmox] XML serialization
>>
>> Catherine... Jon...
>>
>> can you create a proposal for a next generation XML serialization?
>>
>> the existing serialization is in current use by SL, OpenSim and  
>> PyOGP,
>> so there's probably going to be a lot of resistance to changing
>> something that currently works and is deployed.
>>
>> keep in mind, however, that OGP does not use XML to represent it's
>> PDUs, it uses LLSD. XML is one of three defined serializations of
>> LLSD. it's a subtle difference, but important.
>>
>> for instance... is there a benefit to explicitly adding support for
>> namespaces to the XML serialization? there was a bit of discussion
>> about this amongst some AWG members, and the consensus was... "why
>> bother? the XML (presentation layer) is not the place where you want
>> to extend the PDU... you want to extend it in the LLSD / LLIDL
>> definition of the interaction."
>>
>> but, i still think it's an interesting idea as it might allow systems
>> that use XML serialization exclusively to extend display and
>> distribution options of various PDUs.
>>
>> -cheers
>> -m
>>
>> On Feb 23, 2009, at 12:56 PM, Jon Watte wrote:
>>
>>> Catherine Pfeffer wrote:
>>>> <llsd>
>>>>  <map>
>>>>     <entry>
>>>>       <key>success</key>
>>>>       <boolean>true</boolean>
>>>>     </entry>
>>>>     <entry>
>>>>       <key>something_i_like_to_eat_on_sundays</key>
>>>>       <string>bananas</string>
>>>>      </entry>
>>>>  </map>
>>>> </llsd>
>>>
>>> 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]"
>>>
>>>
>>> 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 :-)
>>>
>>> Sincerely,
>>>
>>> jw
>>>
>>> _______________________________________________
>>> mmox mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmox
>>
>> _______________________________________________
>> mmox mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmox
>>
> _______________________________________________
> mmox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmox