-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use of ids:idsValue when referencing portions of IFC schema #39
Comments
ids:idsValue is a choice between either simple value (fixed) or xs:restriction (which can be be minvalue, maxvalue, pattern, enumeration, etc). |
I don't dispute using idsValue, that makes perfect sense. The issue is with using it in places where a string (no regex or enums) offers a stricter and more useful information, such as in L130 and L131. |
Again, idsValue is a choice. <ids:value>
<ids:simpleValue>L130</ids:simpleValue>
</ids:value> |
yes, I fully understand that. <xs:element name="propertySet" type="ids:idsValue"/> My argument is that having the option to set a regex to define the property set name is detrimental to the infrastructure of IDS. (see points 1 and 2 in the initial post). |
We discussed this yesterday in the meeting as well. There are a lot of identified use-cases that require thisL https://github.com/buildingSMART/IDS/tree/master/Use-cases |
For BIM authoring tools we need to have an explicit value for property set and property names. With this information the authoring tools can configure the property sets for their users to fill in. |
When sending an IDS to a BIM Authors, the sender needs to make sure the values for properties are simple values. Many other use-cases for checking require some kind of intelligence. |
Hi @berlotti, Say that we have a propertyName pattern that accepts both If we want to guarantee consistency the same exact selection behaviours will have to be replicated in all applications downstream, I see this unlikely to happen. I don't see how it benefits the IDS to allow multiple (possible conflicting) ways to store the same data, particularly since we accept that IDS is to serve specific atomic transactions. Can you point us to use cases that need this feature, so that we can think of an alternative solution? |
I think that's a separate topic. It could also be the case the a psetname is not specified and the prop is found multiple times. The same for layered materials. Very important that this behaviour is clearly defined, but there are many ways by which a constraint will be mapped to multiple values from the model.
I'm more optimistic. This has to happen. We need to have a formal unambiguous understanding of what we encode in an IDS. |
@aothms, If a difference between the two cases exist, it might be that in the case of materials the process can be defined strictly within IDS behaviours, while for patterns it might also have to consider the order of values that the user writes in the specs. Which might be less intuitive for final users to understand. |
We should indeed eliminate any behaviour related on order. Both I see two ways around it:
I see two cases for patterns in psets/props:
Both can be handled I think if we settle on |
Discussion in April 5th: Property set and property names should be expressed as explicit strings. Agreement between @pasi-paasiala @CBenghi @rubendel @MatthiasWeise and Robin. |
This should also apply to entity types and attribute names. |
There does not seem to be consensus yet in this issue.... Hoping to get some more input here. |
If applied to entity names, then it becomes impossible to say that a list (enumeration) of IfcClasses have a requirement. This is a pretty fundamental usecase of IDS. So I am against this. If applied to attribute names, that makes it much harder to handle schema differences where attributes have been renamed between versions (in particular Identification, ItemId, ...). So I am also against this. Addressing the two original concerns:
Here are some test cases covering the combinatorial explosion you speak of: https://github.com/IfcOpenShell/IfcOpenShell/blob/0dfe1d995f25ce6b519a82e57e62361cea108b21/src/ifcopenshell-python/test/test_ids.py#L767-L800 - the assumption here is that "all" shall pass.
If the recipient has information requirements that state they need exact pset names and property names, then they should not use the restrictions (pattern / enum) in their IDS. If the recipient simply wants to check a pset or prop naming scheme, prefix convention (e.g. no custom psets, all must be Pset_ or Qto_), etc, these restrictions are valid. Common for a company standard, or government standard. If the recipient needs to check multiple Pset_[a-z]+Common psets (LoadBearing, FireRating, AcousticRating, Status especially) or base quantities, these restrictions are valid. If the the recipient is expecting generated psets with variable properties to be processed by their system, these restrictions are valid. If these five usecases (entity names, attribute names, namespaces, *common, and generated props) are invalid, then by all means drop the feature. But I don't think they are all invalid. |
I would like to note that I personally have just written about 70 IDS specs (and counting, still a WIP) and I have yet to need xs:restrictions on attribute names, pset names, and prop names. So at least right now, it seems as though I haven't needed to use them yet - though I suspect the usecase of "applicable to things with a fire rating" or "applicable to anything of a status of demolished / new / whatever" is probably needed. I'm also curious on what usecases @berlotti is referring to here: #39 (comment) |
Hello,
after the group call this week, I've been pondering about the use of ids:idsValue when pointing to named parts of the schema as in:
IDS/Development/0.5/ids_05.xsd
Lines 128 to 131 in 9f85b90
@NickNisbet makes the point that this allows the inclusion of people that cannot quite control the placement of information in the schema. Which is, of course, valuable for all of us.
But the solution proposed generates two major drawbacks, in my view.
I think that the point of IDS is to provide some level of confidence that the data we need can be identified with certainty, and my concern is that the use of multiple options reading several parts of the model results in a high risk of combinatorial explosion of dissimilar models.
In my view an IDS will have to be written on the agreement between consumers and providers, and by that time a specific constraint on PropertySet names, or Classification system names (just as two examples) should be feasible.
The previous state (i.e. fixed names) would allow the automation of editing helpers (e.g. production of a propertySet template) that scaffolds the data input features to enable users to fix models and help them pass the requirements.
This becomes much more arbitrary if we think of all possible combinations of content in the idsValue structure.
At this stage I think this might be a serious misstep for IDS. I would urge the group to reconsider this choice.
As an alternative solution, I would much rather have two or three IDS options of clear behaviours that different providers must comply with, than retain the need to adopt complex extracting behaviour across all reading operations.
Thanks,
Claudio
The text was updated successfully, but these errors were encountered: