[webservices] A question of location ID, how to represent empty IDs in XML?

[Joachim Saul]

Hi Chad

Chad Trabant wrote on 27.07.2014 04:52:
> The answer that empty strings are technically possible and it all
> works in Python/SeisComP is less than satisfying.  The observations
> from Python, ObsPy and SeisComP are a few of many that need to be
> taken into account.

Please name a few. Not abstract claims or hearsay. Point us to client
code that cannot parse an empty location code; only then someone can
take a closer look at the matter and quite possibly provide help.

> Yes, we would need to treat empty location IDs and "--" as synonyms
> for a very long time.  Empty strings in XML mean you will need to map
> empty IDs to empty strings, NULL and whatever an XML parser might or
> might not produce for a long time as well (think beyond Python and
> SeisComP).  Either is possible, only one of them is a unique
> mapping.

I don't accept the parser issues unless you provide examples; see above.

In general mappings are not the problem and are widely used anyway. Can
you name a single software that when reading (Mini)SEED does *not* map
the location code from "  " to ""? Even libmseed does!

So why not be consistent and do the same when parsing XML? It would
solve the current issues. You can then keep your two spaces as long as
you like. ;)

> If the main considerations are for the least amount of disruption the
> the answer is obvious to me: the FDSN can sanction that the two-space
> string is the XML synonym for the empty SEED location ID and we
> adjust the schema to make sure a string of whitespaces is preserved.
> Then SeisComP can change its relatively new StationXML implementation
> and ALL existing clients will be compatible with all metadata and,
> mostly importantly, we would have consistent metadata.

Chad, this whole discussion started back in early January with your
complaint about the SeisComP fdsnws server implementation. You were
alleging that 'The resulting StationXML includes empty location IDs
(locationCode=“”), this is not allowed in SEED and therefore not allowed
in StationXML.' If the SeisComP server were indeed producing wrong XML
it would have been corrected long ago. But that's not the case! It's
actually SeisComP that produces the more correct FDSN StationXML
compared to IRIS XML, not only w.r.t. locationCode.

Don't you think it is now time to roll up the sleeves and make your
client codes work with standard compliant FDSN StationXML rather than
doctoring an FDSN standard?

> If the empty string ID representation is adopted it would would, in
> effect, mean that the DMC would need to change its metadata service
> and (more importantly) all users of the DMC's metadata service would
> need to transition to a new metadata channel naming scheme.  This is
> certainly not out of the question, but it is not something we would
> do without careful consideration.  I do not find the two-space
> strings all that great, but they are here and something the DMC and
> users of the DMC have dealt with.  Issues have been identified with
> empty location IDs by us and our users.  If DMC is going to change,
> and push the change on all users of the DMC's StationXML, it would be
> much more compelling to have a solution that addresses the low level
> issues.

Did you read my email of Thursday, 18:43 UTC? Following the ideas I
outlined there, you are technically *not* required to change any of your
servers. Only a few client codes are actually affected and even I was
able to make the changes in one of those in 10 minutes. Of course, in
total it will take longer, but if specific problematic cases related to
parsing are identified and discussed, I am sure solutions can be found
quickly. We have this list, we have skilled and enthusiastic people
working on this, so why not use this as a platform even for more
technical discussions? Or how about creating a "developer's corner"
webservices-devel or so?

Cheers
Joachim