[sac-dev] Subroutine interface to SAC XML datasets

[Robert Casey]

	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: