[prev in list] [next in list] [prev in thread] [next in thread]
List: xml-dev
Subject: RE: [xml-dev] Four fine text-based data formats ... liberate yourself from one (silo) data format
From: "Toby Considine" <Toby.Considine () gmail ! com>
Date: 2013-03-25 12:59:24
Message-ID: 06a101ce2958$943698f0$bca3cad0$ () gmail ! com
[Download RAW message or body]
All these Manichean (there is light and there is dark and you have to
choose) approaches to data leave out that there are many hybrid approaches
when they fit.
For interactions between multiple partners or even versioning between
different version of the same system, a canonical description of what
information we are sharing and how to recognize what version is immensely
useful. It is even better if that description can make itself available to
tooling, to simplify programming and improve accuracy. People who dispute
this should go all out and turn off all compiler bug checking as well - real
programmers don't need that.. The XSD is a fine tool for this, especially
when supplemented by Schematron, CAM, or the like. It is an added advantage
that the description itself can be transmitted and potentially understood by
any client able to receive the data message.
It is not uncommon for an information model described by XSD to be
transmitted in JSON or in CSV, or in compressed XML, or in COAP. There are
even standards committees working on standard JSON encodings for certain
types of messages in the IETF, in OASIS, and in other places. The notion
that JSON is distinguished from other formats because it never has process
is a false one. Sometimes it does, sometimes it does not. Encoding is
entirely separate from whether the information being encoded has been
standardized or even documented.
Interaction patterns can be document-exchange oriented (DAV, REST, much
JSON) or message oriented (SOAP, COAP). The decision to use
document-exchange or messaging patterns is often driven by matters such as
security, composition, logging, or even pre-processing to improve core
system scalability. Those issues are a long way from this argument.
In not very complicated systems (or in control systems) the interaction
pattern is very small and discrete, peeks and pokes at a distance. I have
seen each of these remote peaks and pokes in XML, REST & SOAP, JSON, ASN,
DNP, or any other messaging structure you care to name.
XSD is not about committees, encodings, or interaction patterns. XSD is
about documenting your work in a way which is machine readable. I have spent
far too much of the least interesting hours of my career reverse engineering
some gawdawful message that some not-as-clever-as-he thinks programmer,
often long gone, has never bothered to document except by his buggy code.
Committees are not immune to this. I have sat in a committee for months
while someone tried to added their old 8-bit encoded error messages as
top-level data type (see the 1 means the status is informational or error,
and the 2 means internal or external, and the 4 and 8 is the 4 codes for the
subsystems., so it is logical to transmit the text "37" for advanced
debugging.everyone will know what that means).
I don't care if your systems *ARE* only internal, and are designed only by
yourself, and you write both sides of every message. Write down your
decisions about messages. Develop your rules. Make them machine readable.
If you do not, those who follow you in an incompetent organization will
curse your name; in a competent organization, they will fire you-as they
should. Life is too short to require that everyone who follows you do
endless searches for the Mayan Codex to figure out your messages.
Unless, of course, your code is all throw-away, Or perhaps if you are a
hobbyist programming your aquarium bubbler.
tc
_____
"If something is not worth doing, it`s not worth doing well " -- Peter
Drucker
_____
Toby Considine
TC9, Inc
OASIS TC Chair: oBIX & WS-Calendar
OASIS TC Editor: EMIX, Energy Interoperation
SGIP Smart Grid Architecture Committee
Email: <mailto:Toby.Considine@fac.unc.edu> Toby.Considine@gmail.com
Phone: (919)619-2104
http://www.tcnine.com
blog: http://www.NewDaedalus.com
From: Uche Ogbuji [mailto:uche@ogbuji.net]
Sent: Sunday, March 24, 2013 11:13 PM
To: Rick Jelliffe
Cc: Simon St.Laurent; xml-dev@lists.xml.org
Subject: Re: [xml-dev] Four fine text-based data formats ... liberate
yourself from one (silo) data format
[Attachment #3 (text/html)]
<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type \
content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 \
(filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);} o\:* \
{behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div \
class=WordSection1><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>All these \
Manichean (there is light and there is dark and you have to choose) approaches to \
data leave out that there are many hybrid approaches when they \
fit.<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>For \
interactions between multiple partners or even versioning between different version \
of the same system, a canonical description of what information we are sharing and \
how to recognize what version is immensely useful. It is even better if that \
description can make itself available to tooling, to simplify programming and improve \
accuracy. People who dispute this should go all out and turn off all compiler bug \
checking as well – real programmers don’t need that…. The XSD is a \
fine tool for this, especially when supplemented by Schematron, CAM, or the like. It \
is an added advantage that the description itself can be transmitted and potentially \
understood by any client able to receive the data message.<o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>It is not \
uncommon for an information model described by XSD to be transmitted in JSON or in \
CSV, or in compressed XML, or in COAP. There are even standards committees working on \
standard JSON encodings for certain types of messages in the IETF, in OASIS, \
and in other places. The notion that JSON is distinguished from other formats because \
it never has process is a false one. Sometimes it does, sometimes it does not. \
Encoding is entirely separate from whether the information being encoded has been \
standardized or even documented.<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Interaction \
patterns can be document-exchange oriented (DAV, REST, much JSON) or message oriented \
(SOAP, COAP). The decision to use document-exchange or messaging patterns is often \
driven by matters such as security, composition, logging, or even pre-processing to \
improve core system scalability. Those issues are a long way from this \
argument.<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> In not \
very complicated systems (or in control systems) the interaction pattern is very \
small and discrete, peeks and pokes at a distance. I have seen each of these remote \
peaks and pokes in XML, REST & SOAP, JSON, ASN, DNP, or any other messaging \
structure you care to name. <o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>XSD is not \
about committees, encodings, or interaction patterns. XSD is about documenting your \
work in a way which is machine readable. I have spent far too much of the least \
interesting hours of my career reverse engineering some gawdawful message that some \
not-as-clever-as-he thinks programmer, often long gone, has never bothered to \
document except by his buggy code. Committees are not immune to this. I have sat in a \
committee for months while someone tried to added their old 8-bit encoded error \
messages as top-level data type (see the 1 means the status is informational or \
error, and the 2 means internal or external, and the 4 and 8 is the 4 codes for the \
subsystems…, so it is logical to transmit the text “37” for \
advanced debugging…everyone will know what that means). \
<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I \
don’t care if your systems *<b>ARE</b>* only internal, and are designed only by \
yourself, and you write both sides of every message. Write down your decisions about \
messages. Develop your rules. Make them machine readable. If you do not, those \
who follow you in an incompetent organization will curse your name; in a competent \
organization, they will fire you—as they should. Life is too short to require \
that everyone who follows you do endless searches for the Mayan Codex to figure \
out your messages. <o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Unless, of \
course, your code is all throw-away, Or perhaps if you are a hobbyist programming \
your aquarium bubbler.<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>tc<o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div \
class=MsoNormal align=center style='text-align:center'><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><hr size=2 \
width="100%" align=center></span></div><p class=MsoNormal><b><i><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>"If \
something is not worth doing, it`s not worth doing well " -- \
Peter Drucker</span></i></b><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><div \
class=MsoNormal align=center style='text-align:center'><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><hr size=2 \
width="100%" align=center></span></div><table class=MsoNormalTable border=0 \
cellpadding=0><tr><td valign=top style='padding:.75pt .75pt .75pt .75pt'><p \
class=MsoNormal><b><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Toby \
Considine<br>TC9, Inc</span></b><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>OASIS TC \
Chair: oBIX & WS-Calendar<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>OASIS TC \
Editor: EMIX, Energy Interoperation<o:p></o:p></span></p><p class=MsoNormal \
style='margin-bottom:12.0pt'><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>SGIP Smart \
Grid Architecture Committee<o:p></o:p></span></p></td><td style='padding:.75pt .75pt \
.75pt .75pt'><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> <o:p></o:p></span></p></td><td \
valign=top style='padding:.75pt .75pt .75pt .75pt'><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Email: <a \
href="mailto:Toby.Considine@fac.unc.edu" \
title="mailto:Toby.Considine@fac.unc.edu"><span style='font-family:"Times New \
Roman","serif";color:black'>Toby.Considine@gmail.com</span></a><br>Phone: \
(919)619-2104<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>http://www.tcnine.com<br>blog: \
http://www.NewDaedalus.com <o:p></o:p></span></p></td></tr></table><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p \
class=MsoNormal><b><span \
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span \
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Uche Ogbuji \
[mailto:uche@ogbuji.net] <br><b>Sent:</b> Sunday, March 24, 2013 11:13 \
PM<br><b>To:</b> Rick Jelliffe<br><b>Cc:</b> Simon St.Laurent; \
xml-dev@lists.xml.org<br><b>Subject:</b> Re: [xml-dev] Four fine text-based data \
formats ... liberate yourself from one (silo) data format<o:p></o:p></span></p><p \
class=MsoNormal><o:p> </o:p></p><div><div><p \
class=MsoNormal><o:p> </o:p></p></div></div></div></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic