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

[Philip Crotwell]

It sounds like you are saying "change is hard, so we shouldn't do it".
I would argue that change is hard and so if we don't do it now it will
never happen. StationXML is new enough that there is already a
disruption, we should seize the chance. If we do not do something now
about null loc ids, it will be a decade or two before we get another
chance.

It is time to drive the stake through the heart of null location ids.
Kill the evil while we have a chance.

Philip


On Fri, Jul 25, 2014 at 9:26 AM, Joachim Saul <saul at gfz-potsdam.de> wrote:
> Hello Rob,
>
> Rob Newman wrote on 24.07.2014 18:51:
>>
>> For what it's worth, I would also vote for the "--" standard. To quote
>> from the Zen of Python
>> <http://python.net/%7Egoodger/projects/pycon/2007/idiomatic/handout.html>
>> (my language of choice):
>>
>>
>> "Beautiful is better than ugly.
>> Explicit is better than implicit.
>> Simple is better than complex.
>> Complex is better than complicated.
>> Flat is better than nested.
>> Sparse is better than dense.
>> Readability counts.
>> Special cases aren't special enough to break the rules.
>> Although practicality beats purity.
>> Errors should never pass silently.
>> Unless explicitly silenced."
>
>
> I'd add "Compatible is better than incompatible." :)
>
>
>> Number 2 is especially relevant here:
>> "Explicit is better than implicit."
>
>
> My favorite would be:
>
> "Special cases aren't special enough to break the rules."
>
>> Quoted whitespace and nulls are painful. Code what you mean, and mean what
>> you code. It's easier for everyone.
>
>
> But what if we simply *mean* "empty string"?
>
> The issue is not about beauty, pain or ease. It's about standard
> conformance. We already have a channel naming standard. If a new data format
> cannot accommodate existing channel naming, then the new format is flawed.
> But that's not even the case here...
>
> An XML document that contains
>
> <Channel locationCode="" ...
>
> is not malformed. There's an attribute that *explicitly* contains an empty
> string and a parser has to produce it as such. Not as null, nil or none, but
> as an empty string. Otherwise the parser is broken and needs to be fixed,
> not the data!
>
> Again: It's not about beauty. We all agree that current channel naming is
> not particularly beautiful and has limitations. But our business is not to
> try to solve that issue now and here.
>
> Cheers
> Joachim
>
> _______________________________________________
> webservices mailing list
> webservices at iris.washington.edu
> http://www.iris.washington.edu/mailman/listinfo/webservices