Hi!
Just to make things more confused, here is another option for
occurrence serialisation in JSON, YAML etc.
Use arrays/sequences with two values for things like?occurrences, that
way it's compact (same number of characters as "occurrences": "0..5")
and almost as readable, but the parser/serializer does more of the job
and will even provide the programmer with data type (e.g. string or
number) or null.
In JSON...
"occurrences": [0, 5]
...and YAML...
occurrences: [0, 5]
The question of how to do with unbounded "*" still remains of course,
one could do valid (ugly but compact) JSON like...
"occurrences": [0, "*"]
On Fri, Nov 11, 2011 at 04:36, Andrew Patterson??wrote:
> Why cant' the absence of a value mean unbounded?
> occurrences = < ?lower = <2>?>
>
> Means 2..*
Then a JSON like...
"occurrences": [2]
... (assuming occurrences are never unbounded in the lower end) or...
"occurrences": [2, null]
?...could mean unbounded upwards. I guess asking an API or programming
language for the second value (index 1 if starting at 0) of the array
will return null in both cases above.
Since the short form of 1..1 often is just written as 1 in UML and
ER-diagrams, the first style with "occurrences": [1] meaning 1..*
should probably be avoided and instead "occurrences": [1, null] should
be recommended for 1..* if humans are supposed to read. (And thus
using "occurrences": [1, 1] if you mean 1..1 and "occurrences": [0, 0]
if you mean 0..0)
It looks a bit scary/ugly though, but probably better than [2, "*"]
and to check for null is in many programming languages nicer than
having to check datatype and possibly string content.
On Fri, Nov 11, 2011 at 04:36, Andrew Patterson??wrote:
> Also, what about inclusive/exclusive values at either end
> of the interval? I know that this isn't an issue for occurence and
> cardinality intervals which are always inclusive - but are we proposing that
> the representation of normal intervals will not use the same mechanisms
> are you are proposing here?
What about using?booleans in an?array/sequence?
"inclusive": [true, false]
...meaning inclusive in lower but not upper end. But perhaps intervals
need a completely different approach.
Was that confusing enough?
Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733
P.s. Off-topic: If this discussion was rushed and had to be decided in
a time-limited face to face meeting we might already have picked the
"0..*"-string version and would have hesitated even to consider the
above as a possibility if it popped up a few days later. (I am just
trying to hint that slow open mail discussions allow more technical
ideas to come forward than rushed meetings. Face to face meetings have
great value too, but perhaps even more for other things than technical
design.)
