Working on pyhaystack, we found that when trying to use range to get histories, the server will not give us result if we don't use quotes around the range in the requests.
The quotes are not mandatory if using strings like "yesterday" or "today"
Requests that work : &range="2016-06-05%2c2016-06-06" &range=today &range="today"
Request that doesn't work : &range=2016-06-05%2c2016-06-06
The nhaystack implementation respond to range with or without quotes.
Is this considered a bug in Skyspark (or more precisely in Zinc encoding) ? If not, we are facing a beautiful interpretation case, so are quotes mandatory ?
Thanks
Brian FrankTue 7 Jun 2016
GET is a little tricky because its really a convenience, but according to the spec:
The tag value must be Zinc encoded, otherwise it is assumed to be of a Str type.
So in both cases the safest thing to do is encode them as a string. Otherwise what happens is that you assuming the fallback will somehow fail to parse and be interpreted as a string. We used to allow this with a format called Trio, and what happens is that as you continue to enhance the Zinc grammar ambiguity starts to creep in.
So I would say the only safe strings that should be used unquoted would be identifier style strings that match the rules for a tag name - anything else should be quoted.
Christian Tremblay Mon 6 Jun 2016
Working on pyhaystack, we found that when trying to use range to get histories, the server will not give us result if we don't use quotes around the range in the requests.
The quotes are not mandatory if using strings like "yesterday" or "today"
Requests that work : &range="2016-06-05%2c2016-06-06" &range=today &range="today"
Request that doesn't work : &range=2016-06-05%2c2016-06-06
The nhaystack implementation respond to range with or without quotes.
Is this considered a bug in Skyspark (or more precisely in Zinc encoding) ? If not, we are facing a beautiful interpretation case, so are quotes mandatory ?
Thanks
Brian Frank Tue 7 Jun 2016
GET is a little tricky because its really a convenience, but according to the spec:
So in both cases the safest thing to do is encode them as a string. Otherwise what happens is that you assuming the fallback will somehow fail to parse and be interpreted as a string. We used to allow this with a format called Trio, and what happens is that as you continue to enhance the Zinc grammar ambiguity starts to creep in.
So I would say the only safe strings that should be used unquoted would be identifier style strings that match the rules for a tag name - anything else should be quoted.
Christian Tremblay Tue 7 Jun 2016
Ok thanks