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

[Joachim Saul]

Hi Chad,

Chad Trabant wrote on 08/12/2014 11:41 PM:
> No argument that the padding spaces should be left behind.

Good.

> Assuming we are unwilling to actually address the blank location IDs we
> should consider making the attribute optional. It has been suggested by
> a few folks already.

The "empty" location code format does need to be addressed, because even
if an attribute is optional, it may be present and it may represent an
empty location code.

Making the location code optional is of course possible. Actually in
QuakeML it is optional, too. There the reason and semantics are special,
though, because in parametric data like picks the location code *may* be
unknown indeed (same for the channel code).

By contrast, in SEED or StationXML the location code is not unknown.

> One could argue that from a purists' point of view a blank location in
> SEED is an unset location, so the purist mapping of this is to leave it
> unset in XML.

A location code that is encoded in SEED as two spaces is not unset but
"empty" and still a string. The purist mapping is therefore the empty
string.

That said we can make the location code optional in XML, but isn't it
really any more than merely a cosmetic trick to hide an "ugly", empty
location code in the XML?

Conforming clients need to be prepared to receive an "empty" (not
unset!) value anyway. In other words, neither of

<Channel locationCode="" ...
<Channel locationCode="  " ...
<Channel locationCode="--" ...

is forbidden by just making locationCode optional. You can leave it
unset but you don't have to. A parser still has to accept at least ""
and "  " (in fact " ", too, as we have just learned). And since
"explicit is better than implicit" it seems wise not to make the
location code optional. Though technically it is feasible provided there
is a clear default value, as otherwise a missing location code might (at
least in principle) be mistaken as unknown like in QuakeML.

> This would be simply done by changing the schema to make
> the attribute optional.  (this is not my favorite idea, I've argued
> against it, but at least it is cleanly follows SEED common practice).

I would prefer to make optional only those fields, for which information
may indeed be unknown, like a digitizer serial number.

> Allowing the value to be optional in SEED (within the limitations of a
> fixed width format) and required in StationXML is trying to eat your
> cake and keep it too.   We do not force other optional string values of
> SEED to be required in the XML, so why make an exception for location?

In SEED, the location code is always present even if it is an empty
string. It's not optional.

But even "optional" still implies the option to explicitly specify an
"empty" location code. And the question of how to properly represent
this in XML is still an open one (even though opinions seem to converge
towards the empty string).

Yazan Suleiman wrote on 08/13/2014 06:17 AM:
> In my opinion StationXml shouldn’t force me to provide a value for
> an attribute that is unknown to me.

But empty is not the same as unknown. The "empty" location code in SEED
does carry a specific information that needs to be represented in XML,
whether we like the value or not.

> While the purpose of StationXml schema is to map between SEED and
> XML, limitations of Seed shouldn’t be carried over.

+1

Cheers
Joachim