It is not mandatory anymore since you don’t need to put it when you don’t redefine the cardinality. But you gave me an idea. Maybe we don’t need to add a new keyword, but just reuse the “cardinality” (or other more descriptive keyword as “container”) and just make the matches part optional:
Multiple attribute with redefinition of cardinality: container_attr cardinality matches {2..*} matches {
Multiple attribute without redefinition of cardinality: container_attr cardinality matches {
I like this idea. It is very close to what is implemented in the java
ADL 1.4 parser. We just need to make cardinality keyword mandatory
again for container attributes in ADL.
Back to one of Tom's questions, "if a compiler uses the RM even in the
parser stage, does it ignore this flag, or report errors when the flag
doesn't match the RM definition?"
I believe the parser should report such errors. Silently ignoring
errors like this doesn't seem to be a good approach to me.
Tom,
I am going to raise the issue of choice and sequence again in this context. I still haven’t seen an example on how groups and choice is going to be implementation in 1.5 but my initial thought was to use a keyword indicating sequence or choice rather than cardinality. However the following suggestion of mandatory cardinality without matches constraint could work ok for specifying sequence using the existing is_ordered attribute, but this does need a default of false when not otherwise specified, which is contrary to the new RM default approach used in other attribute.
Hi Rong,
Like most compilers which have multiple stages where parsing is only an early step, I think we need to separate the adl parsing from the RM validation. This would still allow an error to be raised but support other tools to intercept between the steps to do something like Peter’s visual representation of RM validation errors and others desire to not have an underlying RM.
because now in ADL/AOM 1.5, archetypes only carry actual constraints
w.r.t. the RM. Cardinality is occasionally constrained, but not often.
We just freed ourselves from useless cardinality non-constraints all
over the place - we don't want to go back to that....
the purist in me doesn't like it, but it's quite a smart practical
solution. Let's ruminate a few days to see if we can get a better
solution or not; I'll put in whatever we have by then.
I have seen no further response here, and my own background cogitations
did not come up with anything better - if we are going to go for non-RM
parsing, David's solution is cleaner than anything else I can think of.
Does anyone want to comment further?
If not, I will create a specification CR on Jira and add this to the
main ADL / AOM 1.5 spec. As always, any substantive change to the specs
always gets credited to the author of the idea, and that is what appears
in the Revision history of the document. David - I am putting you down
as the author of this change (in Jira and in the spec). Let me know if
anyone else should be credited.