[XQuery Talk Mailing List Archive Home] [By Date] [By Thread] [By Subject] [By Author] [Recent Entries] [Reply To This Message]

Serialization of XDM

David A. Lee dlee at calldei.com
Mon Sep 14 11:48:31 PDT 2009


  Serialization of XDM
I agree with your sentiment
*"if not you can serialize and parse them without loosing any information."

*but not the implication.

This is (partially) true, but the problem with this is there is not 
*standardized* way to do this.
For simple things like say sequences of nodes, you can wrap them in a 
document.
Or for say integers you can wrap them in something like an <integer> tag.
The problem is there are a *million* ways to do it ... which means no 
vendor has agreed, which leaves it up to the programmer to do it.
Which means you have to cooperate on both sides of the equation, and 
since there is no standardized way to do it, different toolkits or 
pieces are almost certain to do it differently, and possibly in ways 
that are difficult to parse.

By "partially" I am refering to the interesting XDM type of attributes,  
which noone can agree at all on how to serialize.
( although you could stick them in an element ... )

So to make this actually work in practice, you must control both sides 
of the partnership, and the serialization in between, and also pass 
"metadata" either by convention or something to make it all work.   A 
programmer, to say take the output of one XQuery, store it in a file, 
then put it back into an external varialbe of another XQuery invocation 
has to do quite a lot of work, the sort of work that XML was designed 
explicitly to *avoid having to do*.

Even defining a standardized schema for 'wrapping' XDM content 
unambiguously in a XML document would be a huge value,
even if the result wasn't pretty, at least it has the potential for 
interchange.

But lets not talk about function items ... I have no clue where to go 
with those ....



David A. Lee
http://x-query.com/mailman/listinfo/talk  
http://www.calldei.com
http://www.xmlsh.org
812-482-5224



Florent Georges wrote:
> David A. Lee wrote:
>
>   Hi,
>
>   
>> There is no standard or even 'community accepted' way of
>> serializing XDM
>>     
>
>   While I used to think this is a problem, more and more I think
> it is not (or at most a little problem we can live with.)  XDM
> is a convenient (and needed) data structure to work with within a
> piece of code (like a stylesheet or a query.)  (BTW this is a
> pity that XProc is not based on XDM, IMHO)
>
>   But if you want to pass information between two different
> pieces of code (like between a query and a stylesheet) you can
> just restrict yourself to nodes.  If you want to pass a sequence
> of integers, you can instead pass an element containing elements
> the content of which are integers...
>
>   So the simple rule: independent pieces of code set boundaries
> between which you can only pass nodes, or even document nodes.
> That's what XML means, after all.  If you use compatible
> processors, you should then be able to configure them to pass
> those nodes in an efficient way, and if not you can serialize and
> parse them without loosing any information.
>
>   Just my two cents....
>
>   Regards,
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://x-query.com/pipermail/talk/attachments/20090914/2d37fe78/attachment.htm


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2011 All Rights Reserved.