[Bug 27498] [ser 3.1]Unfailing serialization

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27498

David Lee <dlee@marklogic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dlee@marklogic.com

--- Comment #10 from David Lee <dlee@marklogic.com> ---
A few years back I started a discussion on this and created a wiki with quite a
few of these issues.

http://xml.calldei.com/XDMSerialize


Mike encouraged me to start with Use Cases ... and I definitely agree.
For example, a primary use case I have is "streaming" XDM producers.  For
example producing log messages or long lived sessions.
The Efficient XML group (while I was on it) had several real world 'customers'
who needed this as well (but for efficient XML), and the solution is non-ideal.
  One example was for "Instant Message" applications.  each message is an XML
Element but the entire stream is a long lasting document because there is no
standardized way of representing streams of XML documents ... The requirement
is to get each message without over-reading the socket ... That may be a edge
case, but consider typical "feeds' ... twitter, facebook, stocks, news, message
queues. 
Or simply log files ... how to parse a log file before its "done" ... 

This site is still up and discusses many of the use cases I considered.  I put
this on hold when I realized I didn't have a clean solution to item types like
maps or functions, and that some use cases have contradictory requirements such
as full fidelity vs minimal output.
An example - do you really need to expose node identity ? without it you cant
reconstruct the XDM perfectly but is that needed ? for what cases ?


Its good to see some renewed interest in this topic.

If we cant get XDM (of some sort ... ) in and out of our XDM Tools using some
format that has a reasonable chance of being recognized by another tool set 
... that a big barrier ... To me, the "human readable text output" is
interesting but not that problematic as any vendor can solve that differently 
... (humans are tolerant of differences).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 6 January 2015 20:55:15 UTC