- From: Rick Jelliffe <rjelliffe@a...>
- To: Peter Hunsberger <peter.hunsberger@g...>
- Date: Wed, 20 Nov 2013 13:00:38 +1100
I'd go further than that: I'd say always optimize for at least one application (or source or platform etc) where it is known. -- At least you first look at this to see if it is appropriate.
The documents have to be good at something rather than good for nothing. If it can cope with one specific use, it may cope with others (as far as completeness etc).
The intent is that you only need glue code on one side of the exchange rather than on both. And your documents can then share the documentation of one side, rather than multiplying analyses.
People already do this a bit: no-one invents New table languages for example.
I think this is sometimes a major flaw in the utility or theory of namespaces: that you want standard vocabularies made independently of input or output (ie application specific information).
Cheers
Rick
On 20/11/2013 2:08 AM, "Peter Hunsberger" < peter.hunsberger@g...> wrote:
David,
that's a good point. If the data interchange is between two points where you have knowledge of the requirements of both then, yeah, optimize for that interchange. And again, that may be multiple programs or applications....
I got distracted by Rogers use of the world "models" and being stuck on data modelling a lot these days that's the only thing I focused on. Time for more coffee...
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
|