Re: [mmox] XML serialization

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

ah! i think i see a bit of a disconnect here.

jon, you're saying you want to be able to use common DOM apis to  
access data in an XML serialization.

fwiw... that's the atypical use at the lab (<insert comments here  
acknowledging that there's more the the world than linden lab>) and i  
mention it not to imply that this is the type of thing that should  
never be done, but simply to point out that the way LLSD XML  
serialization layer was intended to be used was as a container for  
something that got de-serialized before the application layer gets  
it's mitts on the data.

so.. ya got your stack... (um.. i apologize for the graph... if you  
change the typeface to something vaguely monospace, it'll look much  
nicer)

Application                                                 Application
      | "a"                                                       | "d"
Presentation                                                Presentation
      | "b"                                                       | "c"
  Transport <------ the great mysteries of the network -----> Transport

it sounds like you want to do some processing at points "b" and "c".  
after it has been received by the transport and before it gets un- 
marshalled / de-serialized.

is this just 'cause you're used to writing code that directly uses the  
DOM, or are you routing to specific application endpoints based on the  
contents of the stuff in the XML?

and also... is this a requirement of your system? or just the way that  
seems right to you?

(not trying to pick a fight... just curious)

-cheers
-meadhbh

On Feb 24, 2009, at 11:23 AM, Jon Watte wrote:

> Catherine Pfeffer wrote:
>> (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).
>>
>
> But you don't actually know whether those digits are actual, valid  
> data until and unless that data hits some real executable code.  
> Additionally, we will likely deal with data types that are naturally  
> atomic ("vector3" or "quaternion") but that are not part of the XML  
> data type set. Sending a vector3 as "<float name="x">x</float><float  
> name="y">y</float><float name="z">z</float>" seems like a bad idea,  
> compared to "<vector3>x,y,z</vector3>".
>
> You wouldn't know whether "123000,-5000000,600000" is a proper  
> teleport destination, or under the surface of the earth, or outside  
> the allowed simulation coordinate space, until you treated that  
> coordinate in the target world space. Thus, the validation  
> capabilities of a possible XSD are limited at best anyway.
>
> I must admit that the main reason I want things in attributes is  
> brevity, and uniformity of handling. If I want to get a node set of  
> all property values of a given entity record, I can simply do:
>
> values = entityNode.getElementsByTagName("value");
>
> Similarly, if I want to get a specific element, I can do:
>
> thePosition = entityNode.getElementById("pos");
>
> This assumes that the "key" attribute is defined as an ID such that  
> the DOM implementation can recognize it. On the other hand,  
> depending on structure, it may mean that they key "pos" can't be  
> used on multiple objects in the same overall XML document, so it  
> might be better to get "matching attribute value" anyway:
>
> thePosition = entityNode.getElementPath("[@key='pos']")
>
>
>>
>> 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 ;-).
>
>
> Personally, I think it's too early to really worry about it too  
> much. I first want rough consensus on the model we're using -- I  
> think most, but not all, participants on the list now understand  
> that interoperating virtutal world objects practically require  
> simulation hosts to talk to other simulation hosts. I also think  
> that most participants understand that a specified client/server  
> protocol would not actually solve interoperability between disparate  
> simulation systems.
>
> But how do we actually define and determine "rough consensus"?  
> Perhaps coming up with some metric for that would be a good first  
> step.
>
> Sincerely,
>
> jw
>
>
> _______________________________________________
> mmox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmox