Re: [xml-dev] ANN: a portable data component -- length

[Frank Manola <fmanola@acm.org>]

On Apr 9, 2011, at 2:23 PM, Stephen D Green wrote:

> On 9 April 2011 18:58, Frank Manola <fmanola@acm.org> wrote:
>> Certainly it sometimes makes sense to provide "redundant" data in this way.  But do you really (a) provide the values in multiple units, (b) provide the conversion factor, and (c) check the values for validity using the conversion factor, which is what is being proposed here?  For example, if you're providing prices for both imperial and metric weights, the prices ought to be in integral units of currency/coinage that people actually carry (no hundredths of shillings), and the weights some values that people in grocery stores can actually measure, right?  And do those numbers really work out so the exact same numbers appear on both sides of the conversion equations?
> 
> Well, we are definitely getting away from the point of Roger's
> thesis, that there are some statements made via XML markup
> that have requirements constraining how they relate to each
> other.

I've no problem with the thesis that there are some statements made via XML markup that have requirements constraining how they relate to each other, and I don't think anyone has argued otherwise.  Most of what Roger described in the message prompting this thread, though, wasn't so much a general thesis, but a *specific* "portable length data component" which had certain characteristics that some of us found dubious.  Assuming this discussion goes forward, it would be clearer if we could apply criticisms of Roger's component against Roger's component, not necessarily against other examples of related ideas (which may, of course, be subject to their own criticisms).  

> My own contributions was to suggest a somewhat
> metaphorical example of prices expressed in different units.
> This is because I come from a business document domain
> and am familiar with price lists, invoices, orders, etc. Plus
> Roger's example was loosely connected to this via books
> which are a bit like products and booklists which to me are a
> bit like price lists. It is stretching the domain a bit to use the
> example of measures variously expressed in various units
> but there are so many ways that measures and units are used
> in marked-up documents that we don't have any trouble keeping
> it real because there are so many scenarios to pick from. In
> actual fact my other domain of some exposure is that of
> specifications and test assertions relating to them and here
> there are definite cases where there is a need to express the
> same statement in various ways - such as internationlisation.
> I can assert that a device has certain requirements regarding
> voltage in one country and related but different requirements
> regarding voltage in another country due to the differing mains
> voltages but the matter of conformance to the spec which
> covers both countries at once means these requirements have
> to be unambigous. So it might be that the values for conformance
> are stated in the spec for every country separately or for every
> voltage separately or it might be that the voltage is made a
> variable and the requirements are expressed in terms of this
> variable. In each case it is an overall aim in writing both spec
> requirement statements and corresponding test assertions that
> each requirement is self-contained and atomic (I learnt this from
> the spec conformance experts) sp that a test case can relate
> to just one specific requirement in the spec via the test
> assertion. That all seemd a bit too involved for Roger's example
> though.
>