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

[Marcelo Bianchi]

Hi Philip and All,

I totaly agree with Joachim, was planning to answer but he was much
faster. What you guys are proposing is not a solution. the station XML
supports nicely the empty string and it is not null. There is a type
difference here in Python and in any other language and can be nicely
handled internally.

Also the location id is not just a string it is a key entry to link
miniseed to metadata and making an exception at this level just
because a user interface cannot proper render it without ambiguity
does not sounds like a proper way proposal.  I am not favorable in
creating an exception that will have to be carried over along the
decades to come. Alternatives solutions for this issue should be
searched on the end user interface.

with my best regards,

Marcelo Bianchi
--


2014-07-25 10:35 GMT-03:00 Philip Crotwell <crotwell at seis.sc.edu>:
> 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
> _______________________________________________
> webservices mailing list
> webservices at iris.washington.edu
> http://www.iris.washington.edu/mailman/listinfo/webservices