(Oops. I didn't realize this was only going between the two of us. In case anyone else is interested...)
>From: "Richard Knapp" <gyp_caver@yahoo.com>
>To: "John Halleck" <John.Halleck@utah.edu>
>Date: Sat, 10 Mar 2001 06:23:56 -0500 (EST)
On Fri, 9 Mar 2001 16:29:15 -0700 (MST), John Halleck wrote:
I will add the following to the top of the CaveXML definition:
xmlns CDATA #FIXED "http://www.CaveXML.org"
>> <!-- general entities for use later -->
>> <!ENTITY % AngleUnits "(Degrees, Bearing, DMS, Mills, Grad)">
>
> If this is intended to go in an enumberation, you need "|" not ",".
Yes. This is incorrect. I also misused them when substituting them back into the DTD.
>> <!ENTITY % InclinationUnits "(Degrees, DMS, Mills, Grad, Percent)">
>> <!ENTITY % LengthUnits "(Feet, FeetInch, Meter, CM)">
>
> No support for divers (Who have depth guages, as covered before on the list.
Actually there is. Under the Format element, I have Depth for u/w surveys to record station depths.
There was a discussion of how to adjust for changes in the water level between surveys. I don't know how
this would be handled unless the depth was attached to the station instead of the shot. That way, a new
depth reading could be done at the start of each survey to "recalibrate" the last station's depth before
continuing the survey.
> No support for GPS (Which is becoming more common.).
Not yet.
> No support for a leveling survey. (Similiar to the divers issue...)
Would Depth cover these? (or a different name?)
> Further on down I see a bias to the way cavers usually survey, that makes
> it difficult to record what surveyors do. (Turned angles on a total station
> involve three points. From, To, and Station. It is important to know
> that it was one shot since the Instrument setup errors are therefore
> correlated which they wouldn't be with a fore and back sight.)
There is only one "From/To" pair in this version (for Wall definition). Is there something else I'm missing?
This is part of the reason I left the raw survey data section out. Too many options right now.
I've helped on a precision survey but never crunched the data (except on running an elevation). I know you
need one station behind, the present station, and the next station. An angle is read to the station behind and
to the station ahead. The turned angle is the difference between these. Is there an accepted method to
record this data?
For Triangulation, you need three stations, three azimuths, and three inclinations, correct? Again, is there an
accepted way to record this?
>> <!ELEMENT CaveXML (System | Cave)>
>> <!-- A file can contain a survey with many caves or a single cave -->
>> <!ATTLIST CaveXML
>> Version CDATA #FIXED "0.01"
>> Source CDATA #IMPLIED>
>> <!-- Version will hold the CaveXML release version this file used.-->
>> <!-- Source will hold information from a data conversion. Some values
>> could be: SMAPS, CMAP, Karst, COMPASS, OnStation, Survex. -->
> xml:lang CDATA #IMPLIED
> Maybe Americans think the world is English, but I don't.
I hadn't gotten to Internationalization yet (next chapter). The next cut should have some of this "fixed". FWIW,
shouldn't all CDATA sections have this? Might be easier to create an entity for this:
<!ENTITY % CXMLText "xml:lang NMTOKEN">
(as per you other e-mail)
>> <!ELEMENT Cave (Name, Entrance?, Surveys)>
>> <!ELEMENT Entrance Location>
>> <!ATTLIST Entrance station IDREF #IMPLIED>
> Many caves are long enough that they are tied to several USGS benchmarks.
> There isn't ONE special point in that case.
Opps! Hadn't thought about multiple entrances. (Don't need a large cave for that to rear it's head.) How
about: Also left out Elevation.
<!ELEMENT Cave (Name, Entrance*, Surveys)>?
> I think the comment therefore reflects a mental view
> that is not generally correct.
Well, that _is_ up for debate.
>> <!ELEMENT Location EMPTY>
>> <!-- This would hold the coordinates in either GPS or Lat/Long for the entrance station -->
>
> And it needs to hold at least the Covariance matrix of the GPS reading
> if one is going to do a proper network adjustment.
I have no experience with that. Could you provide an example?
On another note.. I left Location as a separate Element since it will have to handle Lat/Long, GPS/UTM, and
? I thought it would be easier to adapt is separately than trying to force it into the Entrance element. FWIW.
>> <!ELEMENT Surveys (Survey+)>
> An xml:lang element might be appropriate here also.
For the element tag? I'll have to read up on that.
>> <!ELEMENT Header (Date, Declination?, Team?, Equipment?, Format?, Walls?)>
>
> This forces an order that I don't think is natural. Maybe
> (Date, (Declination|Team|Equipment|Format|Walls)?)
> instead?
I've thought about this kind of format a lot. The order is not important. What _is_ important is making sure
either zero or one of the items are included. With the "(Declination|Team|Equipment|Format|Walls)?"
statement, wouldn't that allow only zero or one from the list (due to the "or")? If I change it from a "?" to "*",
then there could be more than one of each. Maybe something to ask on xml-dev, eh?
> I'd much prefer an ISO date, which is trivial to break up, and
> can be sorted and indexed directly. (And, as has been pointed
> out on the list before, allows for ommisions of least significant
> fields.)
True. Please consider this a space holder until I get the ISO date in there.
>> <!ELEMENT Declination EMTPY>
>> <!ATTLIST Declination
>> Value CDATA #REQUIRED>
>> <!-- The magnetic declination for this date. If included, the value must be given -->
>
> What are the units? What is the assumed accuracy?
My fault. Adding Units (AngleUnits) and Accuracy. Does accuracy need units, too? (see also discussion on
Instruments as far as Accuracy, SD, SE, etc)
> In lava tubes this number changes from station to station.
Yep, nothing like getting readings 10deg off only 5ft/1.5m away.
Hence the need for turned angles.
> (But I'm just nit picking.)
Nag, nag, nag. ;) (I'm right handed)
>> <!ELEMENT Role EMPTY>
>> <!ATTLIST Role
>> Job (CDATA, Instrument, Book, Sketch, LeadTape, BackTape, FrontSight,
>> BackSight, Inventory, Other)>
>> <!-- a rough cut at the roles -->
>
> (: FundingAgencyVIP Accident-Waiting-To-Happen :)
> What's a BackTape?
Should be Front/Lead and Rear Tape. Maybe be good to have just plain jobs, too (Tape). Hmmm... do u/w
surveys use different names?
>> <!ELEMENT Equipment (Instrument+)>
>> <!-- The instruments used in the survey. If the Equipment element is present, there
>> must be one or more instruments defined -->
>>
>> <!ELEMENT Instrument EMPTY>
>> <!ATTLIST Instrument
>> Kind (Compass, Tape, Inclinometer, Other) #REQUIRED
>> Correction CDATA #IMPLIED
>> Accuracy CDATA #IMPLIED
>> SerialNumber CDATA #IMPLIED
>> Owner CDATA #IMPLIED>
> Accuracy? Standard deviation, Standard Error, Variance, ?
> And assuming I've given which form of accuracy is being used,
> how do you say what units it is in?
Which items should be here? I know I need Units but I don't know which 'correction' units are needed. Is it SD
and Variance or Accuracy and Standard Error or ?
> The "Accuracy" for a GPS fix is a Three by Three positive definite
> symmetric matrix.
Should this be broken out for each instrument type (Compass, Inclinometer, Tape, GPS, ?) or is the current
format valid?
>> <!ELEMENT Format (Item+)>
>> <!-- A format has a list of items in the order they appear in the survey book -->
> Some surveying formats (as found in books on surveying) change that
> from line to line. (See the example in my paper
> http://www.cc.utah.edu/cave/survey/internaal-angles-example.html
> for example.)
I'll take a peek. Thanks, I think.
> In case you weren't using one, I'll point you at:
> http://www.stg.brown.edu/service/xmlvalid/
Thanks. I'll also dig around on XML.com and see if there are some I can download. I'm trying to use
XMLOperator but it is incredibly slow. (It also will output a DTD which it refuses to read)
> (And DTD's are REQUIRED to have an <?XML as line one, WITH AN ENCODING DECLARATION.
> Note that the encodeing declaration is optional on a regular XML file, but not
> in a DTD.
I couldn't find this in the XML Spec or in other texts. What I could find is the only time <?xml is required is if the
DTD is in the XML document (using a <!DOCTYPE element)
>> Units (Null, Feet, FeetInch, Meters, CM, Degrees, DMS, Bearing, Mills, Grad, Percent) #IMPLIED>
> Is From and to implied by something outside of this shot?
I don't know. Maybe it would be better to have From, To, and Station to support one and two line formats.
> On the other hand, it is something that allow for repeated measurements.
> (And many proposals I've seen don't.)
>
>> <!ELEMENT Walls>
> And how does one do walls with a splay shot in a room?
> (Ugly problem... just to think about.)
Me neither. Next question?
>> <!-- General purpose Elements -->
>> <!ELEMENT Name Empty>
>
> Actually needs to be "#EMPTY".
>> <!ATTLIST Name
>> Value CDATA #IMPLIED>
I couldn't find a reference to #EMPTY. The "#" is attached to attributes attached to the ATTLIST, not to the
ELEMENT. Or is the the case? It should have been all caps.
> How to put in comments?
Comments are probably the only PCDATA item I've considered entering. Now, as to where to put it, I think
they need to be almost everywhere. I'll add the definition to the bottom the start sprinkling them through the
DTD.
I'll fix what we've gone through and continue reading on some of the other stuff.
Thanks for the feedback.
- Richard Knapp
===================END FORWARDED MESSAGE===================
- Richard Knapp
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
This archive was generated by hypermail 2b30 : Mon Apr 02 2001 - 18:00:00 CEST