Are complex restrictions applicable to all facet parameters? about ids

[andyward]

A pattern on PropertySet is a relatively common usage (not least to allow wildcard matches). There's a pset testcase example here: https://github.com/buildingSMART/IDS/blob/development/Documentation/testcases/property/pass-all_matching_property_sets_must_satisfy_requirements_1_3.ids

I don't see any problem combining multiple complex restrictions together for specific use cases. Just a very simple use case: Doors and Windows should have an acoustic rating within a range :

PropertySet: pattern Pset_(Door|Window)Common
BaseName: AcousticRating
Value: bounds between 0 and 0.2

But clearly UXs need to adjust so that the simple case is clear/easy to both author and read, while still allowing more complex restrictions to be built. At the end of the day it's a query builder, but no doubt some queries may be considered too advanced to display in a simple interface. (perhaps similar to how some SQL queries may be too complex to edit graphically)

I can see certain complex restrictions may be inappropriate for certain facet properties. e.g. I can't see many people using Bounds or Length on a propertySet or entityName, unless there's something really esoteric going on. My general view would be that IDS verification should be comprehensive and support these edge cases, but editors may want to be more pragmatic - albeit I feel they should not be discarding / corrupting IDS content they don't support

I'm not sure that we should be deliberately limiting the functionality of IDS simply because of UX difficulties building more complex specs.

BTW: Also worth noting an additional complexity detailed in #285 which you may want to consider in the UX - there can be multiple restrictions defined.

[pierremonico]

Thanks for the reply @andyward, that helps. Your point is valid and the example makes sense. I still think others (like range in a PropertySet) are very uncommon, but yeah, we should stay flexible.

We will do our best to somehow catch that then.