John Halleck wrote:
> I think my personal view differs fundementally from Ralph's.
>
> I favor having canonical forms and units, BUT ALSO leaving the
> original ones around. You then don't have to "recreate" the
> original, you still have it. (And programs that do further
> processing still have standard units, so that they don't
> have to be aware of all the conversion strangeness.
>
> In my view there would be the "original" text, and there
> would be the parsed result (since only the parser is likely
> to know the details of what was what and in what units)
> [In this case I agree with Ralph that there should be a
> standard way to do this.)
> And there would be a cannonical (standard units, etc.) form
> that further processing could use. (And I vote for metres.)
>
> I would have "raw" point names, and "cannonical" point names
> (Since they are a language specific issue).
>
> My view of the world, which many may argue with (and have),
> is that each processing pass adds to the file, with nothing
> removed (except possibly some prior version of it's own stuff).
> And my view is to go out of my way to make incremental updates
> practical, even if that means some things are done differently.
I do not totally disagree with any of this. I think it is very important
to at least support your view of the world.
It is important that no processing results in information loss except
when data is deliberately discarded. This might not require that the
original file be preserved verbatim, punctuation and all. For instance a
process that only adds new elements, all of which are distinguishable
from the old, is information preserving because it is reversible.
Also, and here I'm pretty sure John will not agree, there may be some
properties of the file (order of elements etc.) that we may define as
not being semantically significant. Any change that only affects those
would be considered information preserving. Also, there might be some
usages that could be considered synonymous, changing from one to the
other would also be OK.
> --- New Suggestion ------------------------------------------
>
> Back in the days when the US Military had lots of money for
> software projects, there was a procedure that they used that
> I think would be appropriate here.
>
> They would solicit differing proposals, and minimal (trivial)
> implementations, and then have everyone comment on each of
> the proposals suggested. (Including having everyone come up
> with a paper giving the specifics of what they thought were
> the points that they thought their implementation did better
> than the others.
>
> Then a general vote was taken, and an effort was made to
> bolt the good points of the losers onto the winner.
And you consider this a model to be emulated?
Are you old enough to remember the genesis of ADA, when it was called
Green? When Strawman and Tinman had nothing to do with the Wizard of Oz?
When the resulting language took more than five years to write the first
working compiler? When the life was sucked out of a whole sub field of
computer science, to the extent that it is only now recovering?
I am.
>
> I think that, for me, the time has come to stop arguing details
> of what CaveXML should be like, and go off and flesh out a
> version matching my ideas so that my ideas can be argued with
> examples (and trivial implementations) rather than with
> academic arguments.
...
> It's time I (and other outspoken folk here) put my effort
> where my mouth is.
I was afraid someone was going to say that.
> I've already got some fast, numberically
> stable code for network adjustements (In Ada 95), so I think
> I can put together a working example on that end of the
> world with a reasonable amount of work.
If I find the time to do a pilot project, it would be a converter
to/from an existing program. I have one already picked out. It's author
has expressed negative interest in doing it himself.
> Since the main discussion has ground down to just picking
> at various points, rather than any radical changes, this
> seems like the right time for us to go flesh out alternatives
> so that people on the list will have as large a choice of ideas
> to steal as is practical. (And, hopefully, we'll all notice
> problems with our suggestions ourselves as we try conversions
> on a few random datasets.)
>
> Ralph? Paul? You all with me on this approach?
> In any case, I'll be going off and writing code...
Just what I need, another demand on my time.
I'll see what I can do.
Ralph Hartley
This archive was generated by hypermail 2b30 : Mon Apr 02 2001 - 18:00:00 CEST