Guillaume,
Guillaume Martin wrote:
First, thanks for your answers.
Steven wrote :
If "c" is always the same as "a" then why you need to have "c" at all ?
For example, if you describe the XML grammar in ASN.1, and if you want
to translate in ASN.1 the well-formedness constraint "element type
match" which tells us that the name in the end-tag must be the same as
the one in the start-tag :
<name>
...
</name>
John Larmouth a écrit :
The best you can do is to use a USER-DEFINED constraint, which will
cause most encoders/decoders to call the application at run-time to
determine if the constraint is satisfied.
I'd like to avoid this way. I've had an other idea. Maybe we can use an
information object set, a table constraint and a component relation
constraint like this :
A ::= CLASS {
&a INTEGER( 1 | 2)
}
IntSet A ::= { {&a 1} | {&a 2} }
MySequence ::= SEQUENCE {
field1 A.&a({IntSet}),
field2 INTEGER,
field3 A.&a([EMAIL PROTECTED])
}
This will work as well, but suffers the same limitation that all the
cases have to be enumerated (this time as objects). Which is okay, as
long as the set isn't very large or infinite.
Regards,
Steven
Guillaume Martin
_______________________________________________
ASN1 mailing list
[email protected]
http://lists.asn1.org/mailman/listinfo/asn1
_______________________________________________
ASN1 mailing list
[email protected]
http://lists.asn1.org/mailman/listinfo/asn1
