Should I ask for better XML?
-
I am receiving an XML file with data like below;
<meterref>00895289</meterref> <readingdate>14/12/10</readingdate> <reading>2</reading> <readingdate>28/09/10</readingdate> <reading>0</reading> <readingdate>23/08/10</readingdate> <reading>0</reading> <readingdate>02/03/10</readingdate> <reading>9</reading> <meterref>00895298</meterref> <readingdate>02/12/10</readingdate> <reading>275</reading> <readingdate>22/09/10</readingdate> <reading>274</reading> <readingdate>02/06/10</readingdate> <reading>274</reading> <readingdate>02/03/10</readingdate> <reading>274</reading> <meterref>00895995</meterref> <readingdate>02/12/10</readingdate> <reading>425</reading> <readingdate>22/09/10</readingdate> <reading>420</reading> <readingdate>02/06/10</readingdate> <reading>411</reading> <readingdate>02/03/10</readingdate> <reading>404</reading> <meterref>00896005</meterref> <readingdate>02/12/10</readingdate> <reading>185</reading> <readingdate>22/09/10</readingdate> <reading>182</reading> <readingdate>02/06/10</readingdate> <reading>178</reading> <readingdate>02/03/10</readingdate> <reading>174</reading>Now obviously I can read down from the top and see which readings go with which meter. I think that xsl cannot easily do that. So my question is, can I work with this data without too much messing about, or should I just go to the provider of the xml and tell them to do it properly? Thanks in advance for any help or advice.
Every man can tell how many goats or sheep he possesses, but not how many friends.
-
I am receiving an XML file with data like below;
<meterref>00895289</meterref> <readingdate>14/12/10</readingdate> <reading>2</reading> <readingdate>28/09/10</readingdate> <reading>0</reading> <readingdate>23/08/10</readingdate> <reading>0</reading> <readingdate>02/03/10</readingdate> <reading>9</reading> <meterref>00895298</meterref> <readingdate>02/12/10</readingdate> <reading>275</reading> <readingdate>22/09/10</readingdate> <reading>274</reading> <readingdate>02/06/10</readingdate> <reading>274</reading> <readingdate>02/03/10</readingdate> <reading>274</reading> <meterref>00895995</meterref> <readingdate>02/12/10</readingdate> <reading>425</reading> <readingdate>22/09/10</readingdate> <reading>420</reading> <readingdate>02/06/10</readingdate> <reading>411</reading> <readingdate>02/03/10</readingdate> <reading>404</reading> <meterref>00896005</meterref> <readingdate>02/12/10</readingdate> <reading>185</reading> <readingdate>22/09/10</readingdate> <reading>182</reading> <readingdate>02/06/10</readingdate> <reading>178</reading> <readingdate>02/03/10</readingdate> <reading>174</reading>Now obviously I can read down from the top and see which readings go with which meter. I think that xsl cannot easily do that. So my question is, can I work with this data without too much messing about, or should I just go to the provider of the xml and tell them to do it properly? Thanks in advance for any help or advice.
Every man can tell how many goats or sheep he possesses, but not how many friends.
Although the example you gave does not exploit XML to its fullest potential, it's a welcome departure from entirely unmarked text files with pipes used as separators. I've seen XML that encodes list indexes in tag names, like this:
<item3>78</item3><item1>34</item1><item0>12</item0><item2>56</item2>So I don't think your situation is quite as bad :-D I think that your answer greatly depends on what you are planning to do with this data, and how hard it would be for the provider to change their code to generate a more XML-like XML for you. If your provider is a utility company in the United States, you will almost certainly be better off just working with the flawed format. Otherwise, you risk spending countless hours convincing them to change the format for you, and then ending up working with that flawed format anyway :-( -
Although the example you gave does not exploit XML to its fullest potential, it's a welcome departure from entirely unmarked text files with pipes used as separators. I've seen XML that encodes list indexes in tag names, like this:
<item3>78</item3><item1>34</item1><item0>12</item0><item2>56</item2>So I don't think your situation is quite as bad :-D I think that your answer greatly depends on what you are planning to do with this data, and how hard it would be for the provider to change their code to generate a more XML-like XML for you. If your provider is a utility company in the United States, you will almost certainly be better off just working with the flawed format. Otherwise, you risk spending countless hours convincing them to change the format for you, and then ending up working with that flawed format anyway :-(I need to present the data in a single field in a meaningful way for a user; Meter Ref: 00895289 Reading Taken 14/12/10, Reading 2 Reading Taken 28/09/10, Reading 0 Meter Ref: 00895995 Reading Taken And so on. The provider is actually a company that my company owns, although the work is being done for another company that we own. I can make them do anything, it is just at some point there will be an argument about cross charging that goes away if I do the work instead.
Every man can tell how many goats or sheep he possesses, but not how many friends.
-
I need to present the data in a single field in a meaningful way for a user; Meter Ref: 00895289 Reading Taken 14/12/10, Reading 2 Reading Taken 28/09/10, Reading 0 Meter Ref: 00895995 Reading Taken And so on. The provider is actually a company that my company owns, although the work is being done for another company that we own. I can make them do anything, it is just at some point there will be an argument about cross charging that goes away if I do the work instead.
Every man can tell how many goats or sheep he possesses, but not how many friends.
I would definitely ask them to make reading items meters' children, rather than siblings. While they are at it, I'd ask them to put dates and values into attributes too. Depending on the technology that they use, it could be as simple as ten-line change on their end. Doing the work on your end invites maintenance headache, with a potential of costing your company a lot more. Especially if someone inherits this project from you, and needs to implement enhancements.
-
I would definitely ask them to make reading items meters' children, rather than siblings. While they are at it, I'd ask them to put dates and values into attributes too. Depending on the technology that they use, it could be as simple as ten-line change on their end. Doing the work on your end invites maintenance headache, with a potential of costing your company a lot more. Especially if someone inherits this project from you, and needs to implement enhancements.
-
I am receiving an XML file with data like below;
<meterref>00895289</meterref> <readingdate>14/12/10</readingdate> <reading>2</reading> <readingdate>28/09/10</readingdate> <reading>0</reading> <readingdate>23/08/10</readingdate> <reading>0</reading> <readingdate>02/03/10</readingdate> <reading>9</reading> <meterref>00895298</meterref> <readingdate>02/12/10</readingdate> <reading>275</reading> <readingdate>22/09/10</readingdate> <reading>274</reading> <readingdate>02/06/10</readingdate> <reading>274</reading> <readingdate>02/03/10</readingdate> <reading>274</reading> <meterref>00895995</meterref> <readingdate>02/12/10</readingdate> <reading>425</reading> <readingdate>22/09/10</readingdate> <reading>420</reading> <readingdate>02/06/10</readingdate> <reading>411</reading> <readingdate>02/03/10</readingdate> <reading>404</reading> <meterref>00896005</meterref> <readingdate>02/12/10</readingdate> <reading>185</reading> <readingdate>22/09/10</readingdate> <reading>182</reading> <readingdate>02/06/10</readingdate> <reading>178</reading> <readingdate>02/03/10</readingdate> <reading>174</reading>Now obviously I can read down from the top and see which readings go with which meter. I think that xsl cannot easily do that. So my question is, can I work with this data without too much messing about, or should I just go to the provider of the xml and tell them to do it properly? Thanks in advance for any help or advice.
Every man can tell how many goats or sheep he possesses, but not how many friends.
-
dasblinkenlight wrote:
I'd ask them to put dates and values into attributes too
I don't think that is a good idea.
Why? The most complete treatment of the attribute-vs-element question[^] that I was able to find mentions the principle of structured information, saying that "If the information is expressed as an atomic token, use attributes." I've been intuitively following that rule for many years, because it is easy to remember, it results in consistent schemas, lends itself nicely to use in automated schema generators, and makes resulting documents more compact. That's why I think that using attributes in this case is desirable.
-
Why? The most complete treatment of the attribute-vs-element question[^] that I was able to find mentions the principle of structured information, saying that "If the information is expressed as an atomic token, use attributes." I've been intuitively following that rule for many years, because it is easy to remember, it results in consistent schemas, lends itself nicely to use in automated schema generators, and makes resulting documents more compact. That's why I think that using attributes in this case is desirable.
From that same document and from the single principle (of the several) that you are referring to. "Attributes are designed for expressing simple properties of the information represented in an element." As an example a font is a property of the text of a book. So the font is an attribute. The text is not. Notice as well that the text itself is a element value. So exactly how would you structure the data of the OP such that an element value has attributes which are properties? Besides the principles (plural) of that link which I also use I can only note that in my experience attributes also suffer from a lack of easy display and no way to comment values (xml comments.)
-
From that same document and from the single principle (of the several) that you are referring to. "Attributes are designed for expressing simple properties of the information represented in an element." As an example a font is a property of the text of a book. So the font is an attribute. The text is not. Notice as well that the text itself is a element value. So exactly how would you structure the data of the OP such that an element value has attributes which are properties? Besides the principles (plural) of that link which I also use I can only note that in my experience attributes also suffer from a lack of easy display and no way to comment values (xml comments.)
Notice as well that the text itself is a element value. A text that does not represent a value of an enumeration should always be in an element, because of the mandatory attribute normalization in XML. So exactly how would you structure the data of the OP such that an element value has attributes which are properties? Like this:
Personally, I would prefer the markup below as more consistent, but the one above is perfectly OK.
<meter ref="00895289">
<reading date="14/12/10" value="2"/>
<reading date="28/09/10" value="0"/>
<reading date="23/08/10" value="0"/>
<reading date="02/03/10" value="9"/>
</meter>
<meter ref="00895298">
<reading date="02/12/10" value="275"/>
<reading date="22/09/10" value="274"/>
<reading date="02/06/10" value="274"/>
<reading date="02/03/10" value="274"/>
</meter>in my experience attributes also suffer from a lack of easy display and no way to comment values (xml comments.)
I tend to disregard display concerns, as XML is not specifically a presentation-oriented language. As far as inability to comment attributes goes, I think that humans should not be exposed to reading and writing XML so much as to need comments. There was an excellent post on the subject[^] ten years ago, which I think is even more applicable today.
-
Notice as well that the text itself is a element value. A text that does not represent a value of an enumeration should always be in an element, because of the mandatory attribute normalization in XML. So exactly how would you structure the data of the OP such that an element value has attributes which are properties? Like this:
Personally, I would prefer the markup below as more consistent, but the one above is perfectly OK.
<meter ref="00895289">
<reading date="14/12/10" value="2"/>
<reading date="28/09/10" value="0"/>
<reading date="23/08/10" value="0"/>
<reading date="02/03/10" value="9"/>
</meter>
<meter ref="00895298">
<reading date="02/12/10" value="275"/>
<reading date="22/09/10" value="274"/>
<reading date="02/06/10" value="274"/>
<reading date="02/03/10" value="274"/>
</meter>in my experience attributes also suffer from a lack of easy display and no way to comment values (xml comments.)
I tend to disregard display concerns, as XML is not specifically a presentation-oriented language. As far as inability to comment attributes goes, I think that humans should not be exposed to reading and writing XML so much as to need comments. There was an excellent post on the subject[^] ten years ago, which I think is even more applicable today.