Re: [xml-dev] What is this principle called: "I' send data in myUOM and

[cbullard@hiwaay.net]

If there is a name for it beyond tolerating noise in the exhange, I've  
forgotten it.

One rubric is:  be strict in what you produce and generous in what you  
consume.   In this sense, past XML itself (the draconian model), there  
is no contract per se, thus all the arguments about internal data  
modesl.

A contract-based exchange and not a blind exchange should have  
signatory parties and that is what is most common in document  
environments that I am familiar with.  Network theorists tend toward  
blind exchange (islands) instead of contracts given considerations  
which in general practice don't or shouldn't happen that often.  I am  
aware of the scaling problems here.  I am also aware that those are  
mostly social issues (life among the mammals).

Thus HTML5.   The more widely something is distributed the more  
tightly and locally and authoritatively it has to be controlled rather  
than negotiated in near time.   These systems will bite you if an item  
is issued too far ahead, ie., beta code in mission critical systems.    
It becomes a nastier problem when the contract for the data and the  
contract for the producer are both shared from the same authoritative  
source, but out of sync, as the case with undocumented and buggy  
XSL-FO.   That turns into He Said She Said if one of the parties  
cannot look inside to find problems.   That is why XSL-FOs are good  
candidates for open source.

len

Quoting "W. E. Perry" <wperry@fiduciary.com>:

> Hi Roger.
>
> I'm here, reading xml-dev as I have pretty regularly these 13+ years.
>
> I'm not sure that there is an established or accepted name for the  
> principle which you describe. I refer to it as "In markup, you are  
> what you produce, not what you consume." In the example which you  
> give, the system producing an output of "1/3 meter" cannot know what  
> other systems might consume that data, nor for what purposes, and  
> certainly cannot be responsible for unknown systems getting data in  
> a form or to a precision which they require. The 'contract' in  
> markup is that each system produce--and in the usual case,  
> publish--output in a form which is knowable and identifiable with  
> that producing system, however idiosyncratic. Other systems which  
> need to consume that data, for whatever purpose, are responsible for  
> fetching it and then instantiating it in whatever form they require  
> internally. This is the converse of the object-oriented interface,  
> where the
> 'contract' is "if you pass me the precise data structure which I  
> require, I promise to execute my particular operations upon it". The  
> principle in markup is that the consumer is responsible for the  
> instantiation of the particular data which it requires (and in  
> markup there is *always* a parse and a particular instantiation  
> required--no non-trivial system consumes markup directly). It is not  
> the input interface which is public, but rather the output. Thinking  
> this way can be difficult, and particularly so if you hope to find  
> interoperability inhering in the object, or in whatever is the text  
> or data exchanged between systems. In markup the particular  
> instantiation of data is a local and a private matter, precisely  
> because such interoperability as we might achieve is based on  
> parsing a general form into a specific one. The particular,  
> fully-specified form is local
> to each system; what systems exchange is a more general form which  
> may be locally instantiated into widely differing particulars.
>
> Respectfully,
>
> Walter Perry
>
>
> "Costello, Roger L." wrote:
>
>> Hi Folks,
>>
>> Suppose that every member in a community is required to exchange  
>> data using one unit of measure. For example, suppose length is  
>> required to be expressed as a decimal value in centimeters.  
>> Consider a system that internally deals with length measurements in  
>> meters. Suppose the system wishes to exchange the value "1/3  
>> meter." Recall that the system is required to exchange values in  
>> decimal centimeters. However, there is no exact conversion of "1/3  
>> meter" to centimeters. Should the system send the value 33 cm, 33.3  
>> cm, 33.33333 cm? In the general case, the sending system has no  
>> insight into the precision required by recipients. Exchanging the  
>> wrong amount of precision could be catastrophic. There is a  
>> principle that a sender should transmit its original data (e.g.,  
>> 1/3 meter); it is up to recipients to convert the data, if  
>> necessary, to the precision they require.
>>
>> What's the name of the principle? I remember someone on this list  
>> talking about it long ago. Perhaps Len? Perhaps Walter Perry? (BTW,  
>> anyone know the whereabouts of Walter?)
>>
>> /Roger
>
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>