Value and size constraints in DBus Introspection XML

[Matthew Bromley-Barratt]

>> ... how about value and size constraints too?



>Would the notation for expressing such constraints be Turing-equivalent, or do you envision something less ambitious?



I think sticking to something less ambitious would be the most productive, and would mirror what other systems do. Not even the complexitophiles in the ITU did that with ASN.1. Trying to invent a Turing complete constraints language is likely to lead to the use of the acronym "YACL", which I fear would do no good.





>How about interdependencies between arguments?

Again I think simplicity would be most productive.

Whenever I've found myself having interdependencies between message fields in, say, ASN.1 or GPB - the equivalent of your question - I've often found that that's an indication that I'm not constructing a very good schema. If the value of a message field changes the meaning or range of another, to me that is a cue to dispose of that first field and replace it with an ASN.1 CHOICE or a GPB oneof. Each value of that first field becomes a version of the CHOICE / oneof containing the other message fields as required. For example,

Foo ::= SEQUENCE OF
{
   a INTEGER (0..1), --- Value controls what b can be
   b INTEGER             --- if a is 0, valid from 0 to 10, otherwise 0 to 100
}

Becomes

Foo ::= SEQUENCE OF
{
   a CHOICE
   {
      b_firstver INTEGER (0..10)
      b_secondver INTEGER (0..100)
   }
}

In generated code this might turn into a union in C, or a class in C# that has a nullable members for b_firstver and b_secondver, plus an enum a for a saying which b should be set.

Looking over the DBus wire format there's no UNION (there is a STRUCT). I think it would get messy to replicate an ASN.1 CHOICE / GPB oneof in DBus wire format. Changing the wire format to make it possible sounds like a bad way to go - it would break a lot of things. I guess the best equivalent in DBus would be to split it out the options into separate methods accepting the different flavours of B:

<method name="ProcessFooVersion1">
<arg name="b_firstver" type="i" direction="in" minval=0 maxval=10/>
</method>
<method name="ProcessFooVersion2">
<arg name="b_secondtver" type="i" direction="in" minval=0 maxval=100/>
</method>

I acknowledge that this approach can quickly become impractical with interdependencies even only a little more complex than this! But it doesn't require anything else to be added to the syntax of the introspection XML (not even my suggested constraints).

So I think for simplicity's sake it's best not to try having a way of expressing interdependency.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dbus/attachments/20190820/b7faea6f/attachment.html>