Richard Knapp wrote:
> On Mon, 26 Mar 2001 15:15:02 -0500, Ralph Hartley wrote:
>
>> Richard Knapp wrote:
>
>>> This makes is difficult to enter data in an XML editor - no overall structure.
>>
>> How so? I would think it would make it EASIER. The data items can be
>> entered in the same order they were originally recorded. I want to allow
>> the structure of the original data (book or other format) to be directly
>> reflected in the CaveXML file, even if parts of the survey were entered
>> useing different programs.
>
> That can also be done while restricting the number of children but it seems to come down to a matter or personal
> preference. I like the way the DOM validation can help ensure a valid XML document structure (parent to child and in my
> case a valid shot). Without some sort of guide, I could enter an invalid shot. It is valid as far as the DTD is concerned and the error will only be caught when the data is processed.
But what IS a valid shot? The data recorded for a shot can vary widely
and still be useable. Shots could include:
Distance, azimuth, and inclination.
Two distances, an azimuth, and an inclination (e. g. Tape and laser
rangefinder).
Distances only.
Azimuths and inclinations only.
Azimuths on all shots, inclinations on some.
Azimuths, distances, and vertical distances (depth differences).
Azimuth and distance on each shot, elevation on each station.
All the above can completely determine the geometry if the network of
stations is complete enough. Also common is:
+-90 inclination and distance (no azimuth). This is a common one. Making
up an azimuth when there isn't one is evil.
And don't forget old surveys where they recorded azimuth and distance
only (no vertical control at all).
How can you allow all those legitemate things and not allow any
"invalid" shots? What do you do if the data in the book IS invalid,
contradictory or incomplete? Going back and correcting it is not always
an option. Not preserving all the data you have is even worse.
> One thing I am a little unclear on: is this a CaveXML format or a middle format that can be transformed into CaveXML or
> CMAP?
A CaveXML format. The Semantics document ONLY says what a file means, it
makes no recomendation whatsoever about what can or should be done to it.
> The example in Semantics seems to indicate the format (with <Default element="(element)">) will be transformed
> into another XMLdocument.
The transformations refered to in the Semantics are NOT intended to be
applied to any document. The DefaultTransform in particular is
distructive, it doesn't preserve the structure of the file. In fact, it
can even take a valid CaveXML file and produce an invalid one!
The transformations are part of the definition of the meaning of a file.
I describe the meaning of a subset of the format, and define the rest as
being equivalent to what it *would* transform to. for example:
<Distance value="2.5" unit="meters"/>
is unambiguous, but what about
<Distance value="2.5"/> ?
It doesn't make sense without the units, but nobody wants to put a unit
attribute (and instrument, personel, phase of moon etc.) on every single
distance, when it is ALMOST always the same.
So I allow
<Default element="Distance" unit="meters">
...
<Distance value="2.5"/>
...
</Default>
To be complete, the semantics document needs to say what that means. It
does that by saying that it has the same basic meaning (The definitions
section will difine "basic meaning") as the result of applying the
transform:
...
<Distance value="2.5" unit="meters"/>
...
It doesn't say that the former should be changed to the latter, it says
that it should be interpreted as meaning the same thing (except that the
structure of the file is different).
>
>>> - I don't think you can use ID as an attribute and as a type (however, neither DTDExplorer or Xeena complained).
>>
>> My view is generally that if the spec doesn't say I can't, then I can.
>> The name of an attribute matches the production "Name". I think the
>> confusion is because of the fact that if an attribute's name is "ID"
>> that does not IMPLY that it is of type ID, but if you can find someplace
>> where it says it is FORBIDEN, let me know. A real objection to using ID
>> as an attribute name is that it might confuse people.
>
>
> I think there is a difference between what the spec does and does not allow and what is good XML technique. There was a
> _long_ discussion on xml-dev on best Schema practices. There are things not prohibited in the Schema Rec that are still
> not good ideas. In this case, the main item - at least for me - is the confusion between the attribute name and the attribute
> value.
Ok, you don't think I SHOULD use ID as an attribute name. That's
different. Would you accept "id" instead? I need a name that reflects
the purpose. I DO want to use the same name for every element that
allows an ID, otherewise it would tax my memory to remember the extra names.
Also, a station (which you will recall is a set of station elements) has
an id which is the value of the ID attribute of one of it's elements and
of the reference attribute of the rest. To talk clearly about what that
means I need to be able to destinguish between the id of a station and
the ID attribute of an element. Right now I have the "ID" type (defined
by the XML spec) the "ID" attribute of a station element, and the "id"
of a station. If you were to suggest less confusing names I might use them.
> I think I misread the statement. I missed that the averaging was only applicable to the CrossSection.
Right. With the INTERPRETATION of the CrossSection. My probelem is that
trying to give a precice definition to data, when the people who
recorded it didn't have one, is like making a silk purse from a pigs ear.
> If that is not true and this is a method of processing the data, I think it is out of the realm of the document's spec.
I agree completely. Even when it deals with processed data (as the final
version must), CaveXML will describe the data, how it WAS processed,
and the RESULT of that processing, it will not say how it SHOULD be
processed. Even if a CaveXML FILE included processing recomendations,
the CaveXML SPEC would not.
> All the tools I use are Java 1.1.6 (or better) since I'm using JDK 1.1.8 under OS/2.
>
> For that, Xeena is available from IBM's AlphaWorks site (http://www.alphaWorks.ibm.com/tech/xeena). I got their tar
> version as the only other option was a Win Exe.
That would be fine. I'll check it out.
Ralph Hartley
This archive was generated by hypermail 2b30 : Mon Apr 02 2001 - 18:00:01 CEST