W3C home > Mailing lists > Public > public-qt-comments@w3.org > January 2015

[Bug 27498] [ser 3.1]Unfailing serialization

From: <bugzilla@jessica.w3.org>
Date: Tue, 06 Jan 2015 20:55:13 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-27498-523-djzuGuIFya@http.www.w3.org/Bugs/Public/>

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.


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
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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:46:00 UTC