Hm... some further thoughts on this. I originally chose the "{0..1}"
curly brackets mini-syntax for ADL because it is the UML 'constraint'
syntax - in UML, all diagram constraints (such as they are) are in
braces (see here
<data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2wCEAAkGBhMSEBIPEBAQExAPFRYVFBMQFRQWGRkUFRQVFx8SHhIYHycfGSUkHBIeIDsgLygsLDg4FiAxQTEqOSYrMDUBCQoKBQUFDQUFDSkYEhgpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKf/AABEIAHUAwAMBIgACEQEDEQH/xAAbAAEBAAIDAQAAAAAAAAAAAAAABQQGAQIHA//EAEIQAAIBAwEDCQMKBAUFAQAAAAECAwAEERIFITEGExQWQVFUlNMiMnEHFSNCVWF0kpOzYpGhtDM1Q1KBJCU0grEX/8QAFAEBAAAAAAAAAAAAAAAAAAAAAP/EABQRAQAAAAAAAAAAAAAAAAAAAAD/2gAMAwEAAhEDEQA/APcaUpQKUpQKUpQKUpQKUpQKVH2hyqt4biK1kkAlmzgd2ACM/HOBXxXlpb5AImVZGxHIyHRJiVYiyt3BnG843HIyKC9StfPLi20hl518u6ARoSdUcyQYx97yKAe3OeANdJuXluihmEwIEpdNA1RrC2l2YZ7D3ZJ7M0Gfyqu3isLuaNtMkVvM6Nu3MsTsDg9xFYqcmmIB6ff/AKkXp1hco9uJcbP2osayaYLa5QyMuEZhA+QrZ9rGRv4b62mLgPhQRerLePv/ANSL06dWW8ff/qRenVypbcqLQT9FN3bC41BeZMqB9RwQugnOTnhQY/VlvH3/AOpF6dOrLePv/wBSL06uUoIfVlvH3/6kXp06st4+/wD1IvTq5Sgh9WW8ff8A6kXp1hX9lJbTWbLeXcgluFjdJmjZShjlPAIDxUdtbTUHlR79h+MT9magvUpSgUpSgUpSgUpSgUpSg+MlojOkjKC8WrQd+7UMH+YqKORUOlkMk7R6JY4kLLiJZjltBC5yMDBYtjGBWwUoNftORFvGSUMu/o3Fgf8Axfdxu7TvbvNdLzkLBIxfVIruZSzARMSsz62T20OnB4MMMMnfvq3f7QjgjaWZ1SNOLMcD4feTwxxNROanvv8AEElrZH/T3pPMP4yN8KH/AGj2z2ld4IQ+U14q2O0rexQygx3T3Ezn6KItExaMMB7b4GNA4fWI4HfYuA+FQeVlokWyb2KJFSNLO4CogAAAgfcAOFXouA+FB2rz+PkJLPeXrzyyR2r3sU6RKkX0vNRQEPzxBdRqjxgY9099egUoPJBsja3N3oLXnSGjlGVbCPKblDG8bmcgYjBxpjQYJB34qrdbEvIdpwdHF5LbI0I+mmkKLH7XOPzwmy3HJR4yTuwe70alB5INk7V5iYKt8Lnos63DvOCkt0ZEMT24D+xgBjkBRggca3jkts2aC4vo3M7Wxkja3aeQyE5iXXhmJYDWOHxxWx0oFQeVHv2H4xP2ZqvVB5Ue/YfjE/ZmoO99tqcXLWtvbxyFIklZpJTGMSPKgUAI2f8ABJ/5FOnX/g7bzTelXS3/AM1n/B239xd1eoInTr/wdt5pvSp06/8AB23mm9KrdKCJ06/8Hbeab0qdOv8Awdt5pvSq3SgidOv/AAdt5pvSp06/8Hbeab0qt0oInTr/AMHbeab0qzdh7T6RbQXIXT0iJJdJOca1Dac9uM1mmofIc/8Aa7D8LB+0tBdqVtbb6xMIY0ae6cZSCMjOnhzjsd0aZ+sfgMndWG+2JbomOwIWIEh71gGTduKwod0rfx+4P4sEVT2TsWK3UrGCWc6pJHJaSRv97yHex/8AnAYFBr+yLCR9oSteuk0kENvJEqjEULSvchubU7ycRKOcPtccaQcVt1YMF4huZogmJY44Wd8D2lczaVzxONDfm+NZ1BP5Q7PaezubdCA88EsaluAaSNlBOOzLVhLNtEDHR9n+Zn9CrtKCH0jaPh9n+Zn9CnSNo+H2f5mf0KuUoIfSNo+H2f5mf0KdI2j4fZ/mZ/Qq5Sgh9I2j4fZ/mZ/Qp0jaPh9n+Zn9CrlKCH0jaPh9n+Zn9Csa4sr2aW2M0dmkcE4lYxTSuxwki4CtEo4v31stKCDb/wCaz/g7b+4u6vVBt/8ANZ/wdt/cXdXqDzDlfy0mi2kHia46Hs0xLcrFFI8TmY/Sa5VBVeajKMASN5NVJvlBkWS6fFpzFq9xGsBkYXMjQQGXWo90hscMe6dWTwrdOhR4debj0yklxpXDEjBLD62QMb66JsqESc6sEIl06OcCKG0AY06sZxjsoNJTl7cc1EC+zGmuZYER45XMcSzwSSgyrxz9GVXeNWeysb/9TkEUjtHbgx2VzOCHYpJNb3JgwjbtSNjUO3eK3tdhWwjaEW1uIXOWjEaaGPeUxgn765m2LbuEV7eBhECEDRoQoIwQoI9kY3bqDUDy5uekaRHbcz0yOz3mTXrltllEndgFsY4kd2N9X5NtqzXOzILi5kSSaTUSy7vrtuI4AjhgbuFbB0CPjzUedQf3V98DSH4cQBjPHdXNrZxxArFGkakliEUKNR3lsDtPfQfU157yBhN/s+2Wd1FtbwxRG0QkFmSNfanYgHBGGEY9kggkvnA9CNaZye2KzbP2fdWzLHdpZ24y2dEqCJTzMoHEdzcVJyO0ENyjjCgKoAAGABuAA7AOyu1TtjbaWdWGkxzRHTNA+NcbHvxuIPEMNxG8VRoMC32bpuZrjVnnkhTTjhzRl357c87/AErBs+V8LLmUiIs0gjU6mLqk/MZGF3kvj2RkjWvfXaxgJvrwsraGjtgCQcHAmyAf/b+tS7TkhI8cAkkaJrB36MFCsARK2mUnOXBhIj0nHvOeOCArScr7Rec1TYEQYsxSQKQjhGKvp0vpZgDpJxnfivtsjbQneZNBURFCpOoFkkQMGKMAyHiNJHZUeTkMWURNcHmYtfMqIwGXnJFc6n1e3gAqNy7m35O+quz7Bul3NxImAwjiiJIJMaKWJwOGXc8d+74UFalKUClKUClKUClKUGrXe1Et9pyvKJQslpAqskM0gJWe6JGY1bGAw499ZnXS277jyt36VXaUELrpbd9x5W79KnXS277jyt36VXaUELrpbd9x5W79KnXS277jyt36VXaUELrpbd9x5W79KnXS277jyt36VXaUEI8tLbvuPK3fpV25EoRs2xVgVZbaEEMCCCI1BBB3jeKt0oJW2diGRlnhcRXcQxHLjIKk5MMi/XQns4jiCDXOxdtibVHInNXUOBLCxyRng6t9dGxuf/g4IIFSpm2diCbTIjmK5hyYplGSpPFSv10bG9Dx+4gEBzZbTZ7m5gIXTAISpGcnnFYnP5apVA2BdqZ5lmTmr4hOej1Eq6ICqzRE+8hzx4g7jg1foFKUzQKUzTNApTNM0ClM0zQKUzSgUpSgUpSgUpSgUpSgUpSgUpSgnbZ2Ktwq+00c0R1QzJjXG+MZGdxB4FTuI3GsfZG2mLm1ulWO7QZ9nOiVBu56Mns714qTvyCCbNYO19kJcIEfUrKdUciHDxuOEit2EZ+BBIIIJFBictHI2bfEEgi1uCCNxBEL7818Y+Q1hgf9HB+WpPKLa7rY31neaRcdDuTHIowlwiwPll/2sB70fEcRkb62Xam2YrWAzzMQi6RhVLMzMQqoqLvYkkAAd9Bg9RbDwcH5adRbDwcH5a+2yuVMM6SORLAYCBKl2hhZNQyCdW7BB4g1nvtKIaczRDWMrl1GQe0b99BK6i2Hg4Py06i2Hg4Py1Wj2jEwZlliKx++Q6kLuzvOd27fXB2nDpV+ei0ye62tcNvA3HODvP8AWgldRbDwcH5adRbDwcH5azL7lJbQxySyXEQSFlVyGDFWZgoUhckEk12i25ERIzMI0ik5svKQik6VbKsTgg6uNBg9RbDwcH5am7V5OW1vNYyW8EcTm6VSyDBKmKbK/DcP5VtD7RiVgrSxhmwAC6gktnAAzvzg/wAqk8qPfsPxifszUF6lKUClKUClKUClKUClKUEHam2LiO8t4I7YvDLr1vqQcFB7T7OM9vHsqT12mCxzNHAYphJIFUtrjigmRHZzwJCMSdwwVxvzmt0rETZMIMjCCENMCJCEXLg8Qxx7WfvoNRt+Xs0oxFDEHDoDrLYCXM6Lbvu3+3EWkI/gA7a4u+XVwmqMQRtLAty0hUOUYW8ujA3/AEeeJYkhcjjmtyXZ8Q4RRjOnOEX/AE/d7Pq9ndXzuNjwPjnIIXwxca40OHPF944nHGg1HlDO15s3apnih5mBLgQrhi4eGJjzhbOAcngO47znFXeVGwnuraNYnVZoJYbiIyZKGSFw4Vsb8HGMjfvzTllCq7M2hpVV1Wtyx0gDLGF8sccT99W4uA+FBpm1OTt/dRo9ybFnhuUmS1+kMBRI2QxvKV1MSX1g6MAqNxqZbfJ08QaaVbeQx2d2iRxqTzc087zKkSsu5VVigO47+AzXpFKDyjZHycXElrG7JaQt0WyQQAOFmMEqznpC6Rgn3CBq4k/dVjZXydOtzBcTraaI57qc28YLRxtPHAqLGGUA4MJcnC72JArf6UHlA+Su7KT6zYl5II0AX2YzJFeLPq0JCoRWXK4wxGTvbJqnP8n1xzpuAtjKelTz9GnLmErPbwRbzoPtIYjj2TuY8M16JSg80HyVSiCSIyQSS9GsoYpZNWpXt5nkdgdJKjDADBJ9kZxW28p/fsPxifszVeqDyo9+w/GJ+zNQXqUpQKUpQKUpQKUpQKUpQKUpQKUpQYe2NnC4t57YsVFxFJEWG8gSIV1AHu1VMGxb37TPloaUoHzNe/aZ8tDT5mvftM+WhrmlBx8zXv2mfLQ0+Zr37TPloa5pQcfM179pny0NPma9+0z5aGuaUHHzNe/aZ8tDXXq3cPLA89+ZUt5BKEEEaZYKyjLDf9c1xSg//9k=>
for an example), I.e. it wasn't anything original. For ADL, it seems
natural to stick with it. But for other syntaxes, Erik is suggesting:
consider using the most natural closest thing in those syntaxes.
In dADL this would be easy, because Interval<Integer> is a real leaf
type, and open intervals are easy to express.
* {0..1} is |0..1|
* {0..*} is |>=0|
* {0..0} is |0|
* and so on.
The options Erik describes below apply to JSON and YAML. Using an array
does mean that there is no inbuilt way to refer to '*'. Personally I
think that if there had been an inbuilt Interval<T> type, then it would
have made sense to use it. But since there is not, you still need to do
some post-processing, and we would also need to document /the /accepted
way to even represent 0..* intervals, since as Erik shows, there could
be more than one.
So on the balance it still seems to me that the single String field
would make more sense, since at least you can read it in the data. I
have to admit, it is now a question of what to use in dADL-represented
archetypes (which the ADL 1.5 reference compiler will start using soon
to persist correctly parsed archetypes), but I think sticking with
String for everything makes it easier across the board. Then all you
have to have in your MULTIPLICITY_INTERVAL type is a constructor taking
a String argument.
I don't really mind which way we go. As long as it's not complicated to
describe and understand in the text, and everyone is happy with it as a
reasonable compromise across all languages and serialisation syntaxes.
- thomas
On 21/11/2011 13:05, Erik Sundvall wrote:
> 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<andrewpatto at gmail.com>
> 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<andrewpatto at gmail.com>
> 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.)
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111121/5c4ce810/attachment.html>
