Richard Knapp wrote:
> CaveXML.DTD:
>
> - The AzUnit and IncUnit need more units. AzUnit could be a bearing, could be in grads, mills, or DMS. IncUnit could be
> DMS, grads, or mills... or could have a length (for u/w surveys or level lines).
Of course. I just put a few in as examples. Someone needs to compile a
complete list of ALL the units people actually use, I didn't have time
to do that yet. Property markers may be surveyed in "chains".
> - There are lots of places you have "ANY" for the element. Do you really want an uncontrolled extension of these
> elements? Is there intentionally no overall format to the document?
I might want to tighten them up a little bit more than ANY, not all
combinations really make a lot of sense. However, it IS intentional that
there is no "overall" format to the document.
> 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.
Insted of requiring data to be organized in a particular way, and then
describing the structure of the original, I allow almost any structure
in the CaveXML file itself.
In fact it is my intention that at lest for the CMAP/CaveXML prototype,
the output of the converter will be both a valid CaveXML file and a
valid CMAP file, with the relationship between them directly represented
(though CMAP will, of course, see the elements only as comments). I
don't think I can decribe exactly how this will work untill the code is
done.
> - 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.
> - You have places where there are multiple enumerations using (true|false). This is not compatible with the SGML spec. I
> encountered this issue on my Exclusion element, too. Mainly a design decision.
Are we writing XML or SGML? The XML spec says XML is a subset of SGML,
but maybe it lies (or did I miss something? Won't be the first time.).
> - Interesting element Provenence.
Gotta have it. As I commented, it may need to be broken up into several
elements.
> Semantics.html
>
> - The text on cross sections is a little confusing; examples might help.
No joke. Examples will be forthcomming. The general rule was that you
can explicity state something or it can be implied by context, with the
former taking precidence.
> - If a shot has more than one azimuth, it says the values will be averaged. Will this be limited to azimuths of the same
> reversed and inverted values or all azimuths?
I don't quite understand the question. Certianly if a shot includes both
for and back sights, they would both be used (with the back sights
converted).
This is one of the points that still bothers me, but I don't think it
matters much. The question is what direction a section was taken in when
the relevant shot has multiple azimuths. There are basically two
possibilities:
(a) All the azimuths for the shot agree.
In that case the averaging is just a way to get a single direction. If
the readings are within 2 degrees, worying about which direction the
surveyors had in mind when they recorded lrud is a bit like arguing
about angels on the head of a pin.
(b) A single shot has at least two azimuth readings that flatly
contradict each other.
Here the true direction of the shot is anyone's guess. If a shot were
recorded both as 0 and 102, how would YOU interpret the lrud?
Rememer that this calculation only affects the "interpretation" of the
cross section, i.e. how it should be plotted on the map. There are three
ways this is done now, and I do cover those (I do wonder how many
surveyors would disagree with their cartographer on this if they
compared notes).
> Overall, I think the lack of structure to the DTD makes it difficult to follow. A full example of the resulting XML might help.
A bunch of examples will be needed. In its current state, I don't think
the dtd is the way to understand it, at least not yet. The semantics are
the primary, get that wrong and no amount of syntax will save you.
> It
> might be helpful to have snips of the DTD in the Semantics document so they are easier to relate.
Before I make it clear to you I need to make it clear to myself.
> I also highly recommend
> getting a validating XML editor to see how the data works. Using one resulted in changes in the version I was working.
With ANY everywhere, it wouldn't help me much. But when I tighen those a
bit...
Do you know whre I could find good one? It needs to be free and run on
linux.
Ralph Hartley
This archive was generated by hypermail 2b30 : Mon Apr 02 2001 - 18:00:01 CEST