One strictly for the ONIX geeks • 11 December 2010 • The SnowBlog
One strictly for the ONIX geeks
I'm not nearly as familiar as Emma is with the ONIX standard and it's time for that to change. But as I'm staring at it now, I'm wondering why they did things the way they did. I hesitate to describe it as 'wrong' because maybe I'm not as au fait with this stuff as I think I am, but I'm certainly finding bits of it 'curious'. Take an excerpt like this: Snippet:
...
<Measure>
<MeasureType>01</MeasureType>
<Measurement>194</Measurement>
<MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure>
<MeasureType>02</MeasureType>
<Measurement>130</Measurement>
<MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure>
<MeasureType>03</MeasureType>
<Measurement>18</Measurement>
<MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
...
In order to find the Measure element for the dimension you're interested in, you have to look inside each Measure and know that it's the code in the MeasureType child element you want to check. Why wouldn't you write it like this instead:
...
<Measure MeasureType="01" >
<Measurement>194</Measurement>
<MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure MeasureType="02" >
<Measurement>130</Measurement>
<MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure MeasureType="03" >
<Measurement>18</Measurement>
<MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
...
It seems easier to use and to make more sense to use an attribute to label each Measure element and to leave the child nodes for data not labels. Is there some reason to do it the way they have?
And if you want to go the whole hog, I don't think much of their naming and code conventions either. If 'mm' can be the 'code' for millimetres, why does '01' need to be the code for height and not 'h'. Plus, the measurements are jumbled in with other information in DescriptiveDetail. I think I'd prefer this:
...
<PhysicalDimensions>
<Measurement Dimension="h" Unit="mm" >194</Measurement>
<Measurement Dimension="w" Unit="mm" >130</Measurement>
<Measurement Dimension="d" Unit="mm" >18</Measurement>
</PhysicalDimensions>
...
Seems to me that's more concise, easier to understand, easier to remember and easier to process if you're writing code to manipulate that data (e.g. selecting it in XPath).
It might be unfair to pick on the ONIX for Books standard like this because I've only looked at little pieces of it. And like I say, maybe I'm not as knowledgeable about XML as I think I am. But so far it looks like big chunks of it were decided very broadly in a committee and then the actual implementation was handled by someone who wasn't all that experienced. (But if it turns out there are wise and good reasons for things being the way they are please enlighten me and I'll stand corrected.)
Rob
I'm not nearly as familiar as Emma is with the ONIX standard and it's time for that to change. But as I'm staring at it now, I'm wondering why they did things the way they did. I hesitate to describe it as 'wrong' because maybe I'm not as au fait with this stuff as I think I am, but I'm certainly finding bits of it 'curious'. Take an excerpt like this: Snippet:
...
<Measure>
<MeasureType>01</MeasureType>
<Measurement>194</Measurement>
<MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure>
<MeasureType>02</MeasureType>
<Measurement>130</Measurement>
<MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure>
<MeasureType>03</MeasureType>
<Measurement>18</Measurement>
<MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
...
In order to find the Measure element for the dimension you're interested in, you have to look inside each Measure and know that it's the code in the MeasureType child element you want to check. Why wouldn't you write it like this instead:
...
<Measure MeasureType="01" >
<Measurement>194</Measurement>
<MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure MeasureType="02" >
<Measurement>130</Measurement>
<MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure MeasureType="03" >
<Measurement>18</Measurement>
<MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
...
It seems easier to use and to make more sense to use an attribute to label each Measure element and to leave the child nodes for data not labels. Is there some reason to do it the way they have?
And if you want to go the whole hog, I don't think much of their naming and code conventions either. If 'mm' can be the 'code' for millimetres, why does '01' need to be the code for height and not 'h'. Plus, the measurements are jumbled in with other information in DescriptiveDetail. I think I'd prefer this:
...
<PhysicalDimensions>
<Measurement Dimension="h" Unit="mm" >194</Measurement>
<Measurement Dimension="w" Unit="mm" >130</Measurement>
<Measurement Dimension="d" Unit="mm" >18</Measurement>
</PhysicalDimensions>
...
Seems to me that's more concise, easier to understand, easier to remember and easier to process if you're writing code to manipulate that data (e.g. selecting it in XPath).
It might be unfair to pick on the ONIX for Books standard like this because I've only looked at little pieces of it. And like I say, maybe I'm not as knowledgeable about XML as I think I am. But so far it looks like big chunks of it were decided very broadly in a committee and then the actual implementation was handled by someone who wasn't all that experienced. (But if it turns out there are wise and good reasons for things being the way they are please enlighten me and I'll stand corrected.)