Not exactly the same thing but…. In OASIS Energy Interoperation, many service payloads had the option of including a full specification or be reference. An energy transaction requiring telemetry verification could fully describe the telemetry required (a report definition) or pass an URI to the report definition. The receiving client could then retrieve it, or “remember” its cached version, etc. When a system delvered a telemetry payload back to a counterparty, it was expected to explain what the pile of number is was sending was. This could again be by including a full report definition as a “header”, or ot could simply reference the originating URI. In this model we treated the URI as if it were a GUID, and the query that identified the GUID was also the path to retrieve it. All of Energy Interoperation, and its component specifications WS-Calendar and EMIX used inheritance and context to reduce payload size. A full payload for any moment in time was necessary to action, but that payload might be constructable by what we termed inheritance. The specifications defined inheritance rules, but just about everything could be inherited from the schedule, from the telemetry specification, from the market context, from the financial option. We did this to support parsimonious communications while supporting a requirement that every market, and every market transaction be self-describing. The requirement came from a goal that any system that manipulates energy use, generation, storage, conversion, … be able to participate in any local market. This meant that the market and market rules had to be explicit and machine understandable. SO, now what you describe, but large information models that could be explicitly assembled from smaller discrete XML documents…or transmitted as one large XML document. tc “The single biggest problem in communication is the illusion that it has taken place.” – George Bernard Shaw.
From: Costello, Roger L. [mailto:costello@mitre.org] Hi Folks, I realized today that I have been assuming that when one application sends an XML document to another application, the entire XML document is sent. I know that at the network (IP) layer the XML document might be broken down into smaller pieces; but at the application layer the entire XML document is sent and the entire XML document is received. I would like to challenge my assumption. Are there use cases in data exchanges where you want to break up an XML document into parts and send the document in parts, perhaps even send the parts out of order, and the receiving application then stitches the parts back together? Here is a graphic to illustrate how an XML document might be broken up.
And the following graphic shows the order in which the parts might be sent from one application to another:
What inspired this question? I am learning about IP. I learned that during transmission an IP packet might be fragmented. To account for this possibility, the IP header contains several data items to enable the recipient to reassemble the fragments. Back to fragmenting an XML data exchange … have you ever broken apart an XML document when exchanging data? Or, perhaps you deliberately made small XML documents that are intended to be stitched together by the recipient? You might respond that XMPP does this kind of thing. Yes, I realize that. But I think of XMPP as an XML protocol format, not an XML data exchange format. Not sure that I could articulate the difference between an XML protocol format and an XML data exchange format. You might respond that XML streaming does this kind of thing. Yes, I realize that as well. But the streamed parts (packets) are always in order, whereas I allow for the case where the parts are not necessarily transmitted in order (just like IP packets might not arrive in the order they are sent). Thoughts? /Roger |
