There a bunch of cases where things get encoded into strings to serialize to/from Haystack. In the case of lists of strings or refs, we can actually encode this with a nested list now. But there are still a plethora of other atomic types that get stuffed into strings:
TimeZones
Units
Kinds
DateSpan (we use these extensively to pick data ranges for charts)
Color
Font
etc...
Sometimes we can infer the expected type from the context such as its tag name. But in many cases, it would desirable to allow the receiver to automatically parse the data and use platform specific types. For example if parsing a color encoded into a string, the parser could represent it with a typed class for Color.
I would like to propose a new atomic type called XStr for extended strings. These are simple string values annotated with a "type name" that can hint to the receive what the string contains. XStrs can be decoded as generic strings, a generic type/value pair, or into a platform specific type.
The type name follows the same rules as a tag name but must start with an upper case letter (only ASCII letters, numbers, or underbar). Value strings are any Unicode chars.
Jason BriggsMon 11 Jan 2016
to confirm, would a zinc encoding of let's say a tag called alarmColor look like this.
alarmColor:Color("#4444")
If so, then I'm + 1 for this too
Steve EynonTue 12 Jan 2016
Unless there's already precedence for strings to be different, I'd be tempted to make the JSON encoding the same as Zinc:
Zinc
Color("#800")
JSON
x:Color("#800")
Also, is there a need for the double quotes? As the value is already delimited by brackets could we not drop the quotes (similar to CSS URLs)?
Zinc
Color(#800)
JSON
x:Color(#800)
Brian FrankTue 12 Jan 2016
Also, is there a need for the double quotes?
If you don't use quotes then you have to restrict the char set to not include ")", or newlines, etc. Then you end up requiring scanning strings for special chars, so much safer to just reuse string literals. Essentially they are by definition just strings with a type hint.
Unless there's already precedence for strings to be different, I'd be tempted to make the JSON encoding the same as Zinc
JSON has to cram everything into a string literal, and we use the prefix for that. Forcing the same syntax would require escaping the quotes:
"tag": "x:Color(\"#FFF\")" // same as Zinc
"tag": "x:Color:#FFF" // as proposed
Brian Frank Mon 11 Jan 2016
This is one component of Data Model 3.0 proposal.
There a bunch of cases where things get encoded into strings to serialize to/from Haystack. In the case of lists of strings or refs, we can actually encode this with a nested list now. But there are still a plethora of other atomic types that get stuffed into strings:
Sometimes we can infer the expected type from the context such as its tag name. But in many cases, it would desirable to allow the receiver to automatically parse the data and use platform specific types. For example if parsing a color encoded into a string, the parser could represent it with a typed class for Color.
I would like to propose a new atomic type called XStr for extended strings. These are simple string values annotated with a "type name" that can hint to the receive what the string contains. XStrs can be decoded as generic strings, a generic type/value pair, or into a platform specific type.
Proposed Zinc encoding is:
Type("value") Color("#800") Kind("Ref") Unit("°F")Proposed JSON encoding is:
The type name follows the same rules as a tag name but must start with an upper case letter (only ASCII letters, numbers, or underbar). Value strings are any Unicode chars.
Jason Briggs Mon 11 Jan 2016
to confirm, would a zinc encoding of let's say a tag called alarmColor look like this.
alarmColor:Color("#4444")
If so, then I'm + 1 for this too
Steve Eynon Tue 12 Jan 2016
Unless there's already precedence for strings to be different, I'd be tempted to make the JSON encoding the same as Zinc:
Zinc Color("#800") JSON x:Color("#800")Also, is there a need for the double quotes? As the value is already delimited by brackets could we not drop the quotes (similar to CSS URLs)?
Brian Frank Tue 12 Jan 2016
If you don't use quotes then you have to restrict the char set to not include ")", or newlines, etc. Then you end up requiring scanning strings for special chars, so much safer to just reuse string literals. Essentially they are by definition just strings with a type hint.
JSON has to cram everything into a string literal, and we use the prefix for that. Forcing the same syntax would require escaping the quotes:
We already use this pattern for coordinates: