[sac-dev] Subroutine interface to SAC XML datasets

[George Helffrich]

Dear Rob -

	The XML DTD is versioned, and one could imagine defining a new DTD 
with alternative element groupings that would reflect the data 
structure.  One can obsess in describing data details, and one view 
won't necessarily coincide with another person or community's view.  
Google Earth's KML comes to mind -- unbelievably baroque for putting 
points on a map for a seismologist, but probably glibly expressive for 
GISers.

	Another view to take of the data is programming semantics, however.  
Programmers see 1) header variables that are peeked and poked at; 2) 
data.  That was the view I took of the present DTD definition.

On 31 Jan 2008, at 00:12, Robert Casey wrote:

>
> 	Hi George-
>
> 	An interesting effort with SAC XML and you've made a lot of progress 
> from the looks of it.  I hate to comment too harshly on something that 
> may already be an established standard, so my comments are only meant 
> as an observation:
>
> 	It seems to me that the SAC XML format only half-divorces itself from 
> fixed-format files due to the naming scheme for the header elements 
> you've provided.  Essentially, you've got just two entity names inside 
> of <trace> that have no semantic quality to them: 'h' and 'd'.
>
> 	The nature of XML is such that the entities tend to me more grouped 
> and self descriptive as far as their names go.  So instead of having 
> <h name="STEL">, why could it not instead be <STEL>  ?  To indicate 
> this as a subcomponent of a SAC header of a SAC trace, you'd form a 
> hierarchy:
>
> <sacdataset>
> 	<trace>
> 		<header>
> 			<stel>
>
> 	Even better would be to just call it <elevation>, maybe with a 
> reference to its SAC field abbreviation as an attribute:  <elevation 
> id="STEL">.
>
> 	The reason for the comment is not just for human readability, but for 
> the notion that many XML parsers will treat such elements as objects, 
> carrying the element name with them.  Having your fields broken down 
> into meaningful names means that your objects will be more independent 
> and have stronger encapsulation properties.
>
> 	If your example format is already set in stone, then please continue 
> with what works.  I just felt the floor was open to address some 
> naming aesthetics for consideration.  I can imagine that writing a 
> parsing engine for XML in Fortran is headache enough, so I don't want 
> to cause you a migraine on top of it.
>
> 	Cheers,
>
> 	-Rob
>
> On Jan 30, 2008, at 5:05 AM, George Helffrich wrote:
>
>> Dear All -
>>
>> 	I designed and implemented a subroutine interface to SAC XML 
>> datasets in the latest release of MacSAC.  This message is to make 
>> you aware of the design ideas for architectural comment.  I think 
>> that it shows the way forward to
>> how SAC can move away from from a purely binary data format to one 
>> that
>> embraces current practice in structuring and delivering data.
>>
>> 	A test program illustrates the concepts.  Here is Fortran source 
>> code of
>> an actual program used for testing during development:
>>
								George Helffrich
								george at geology.bristol.ac.uk