that file (the version I took from the MSE4Java) doesn't seem to comply to the MSE-specification. Element-node with (id: 29) uses (name Transcript) while this should be (name 'Transcript'). I hope that other readers than the one I am writing for python, also break on this?
Then I saw that there are still some specification-errors on the MSE-spec website (<boolean, <path> is still used but not defined)
cheers, toon
@akuhn
Oh, and next to this it would also be nice to have some clarity on the "ref: ...." matter. Are you going to allow this? Is this useful? This breaks the use of a general-purpose reader. If you would just do as you did before, (FAMIX.Class (id: 2) (name 'Boolean')) this would allow the interpretation of the model to do the filling of known classes, while in your case, the reader already has to do some magic.
I am just talking about this since the FAMIX30.fm3.mse file that I got uses this stuff; and I am not sure if I am going to implement that part. If not, it would be nice to see a "clean" fm3 file somewhere which doesn't use undocumented new features. Another one are those comments in the MSE-file. That plus the fact that you really really want to have ((..) (..)) to show that you have multiple elementNodes in a file (while you could just read until the EOF) makes implementing an MSE-reader a bit a pain in the butt. I would just read elementNodes until the end of file, but since you want that double (( for some strange reason; I skip one if there are 2. But now all of a sudden 15 lines of comment have appeared so I had to find another way.
lastly, my email (comment in FAMIX30.fm3.mse) is not tverwaes@ but verwaest@. (maybe this should change; it's confusing :))
cheers, Toon
Toon Verwaest wrote:
that file (the version I took from the MSE4Java) doesn't seem to comply to the MSE-specification. Element-node with (id: 29) uses (name Transcript) while this should be (name 'Transcript'). I hope that other readers than the one I am writing for python, also break on this?
Then I saw that there are still some specification-errors on the MSE-spec website (<boolean, <path> is still used but not defined)
cheers, toon _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 2 Dec 2007, at 22:53 , Toon Verwaest wrote:
@akuhn
Oh, and next to this it would also be nice to have some clarity on the "ref: ...." matter. Are you going to allow this? Is this useful? This breaks the use of a general-purpose reader. If you would just do as you did before, (FAMIX.Class (id: 2) (name 'Boolean')) this would allow the interpretation of the model to do the filling of known classes, while in your case, the reader already has to do some magic. I am just talking about this since the FAMIX30.fm3.mse file that I got uses this stuff; and I am not sure if I am going to implement that part. If not, it would be nice to see a "clean" fm3 file somewhere which doesn't use undocumented new features.
Yes, I'd like to have them as built-in types that must not be defined in the mse file. The main reason is that primitives are shared between M2 and M3, and also implementation is simpler. It is just five lines of code to initialize the name lookup in your MetaRepository and saves a lot of trouble later if these built-in types are unique among all repositories, eg in the exporter etc any place where primitives needs to be hardwired anyway.
Another one are those comments in the MSE-file.
Oops, missing in the spec you are right! Anything between "..." is a comment and should be treated as if whitespace.
That plus the fact that you really really want to have ((..) (..)) to show that you have multiple elementNodes in a file (while you could just read until the EOF) makes implementing an MSE-reader a bit a pain in the butt. I would just read elementNodes until the end of file, but since you want that double (( for some strange reason; I skip one if there are 2. But now all of a sudden 15 lines of comment have appeared so I had to find another way.
See ch.akuhn.mse.serialization.Parser.accept(...)
lastly, my email (comment in FAMIX30.fm3.mse) is not tverwaes@ but verwaest@. (maybe this should change; it's confusing :))
Fixed.
cheers, Toon
Toon Verwaest wrote:
that file (the version I took from the MSE4Java) doesn't seem to comply to the MSE-specification. Element-node with (id: 29) uses (name Transcript) while this should be (name 'Transcript'). I hope that other readers than the one I am writing for python, also break on this?
Then I saw that there are still some specification-errors on the MSE-spec website (<boolean, <path> is still used but not defined)
cheers, toon _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Genau, that file is very old (back then it was allowed to omit quotes fors strings that do not contain whitespaces).
The Java reader also breaks on this.
AA
On 2 Dec 2007, at 22:35 , Toon Verwaest wrote:
that file (the version I took from the MSE4Java) doesn't seem to comply to the MSE-specification. Element-node with (id: 29) uses (name Transcript) while this should be (name 'Transcript'). I hope that other readers than the one I am writing for python, also break on this?
Then I saw that there are still some specification-errors on the MSE-spec website (<boolean, <path> is still used but not defined)
cheers, toon _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Adrian Kuhn -
Toon Verwaest