Comments (14)
Can we please bring back the attribute cardinality? I really don't get the logic for this. There are clear test cases and documentation describing how it is interpreted.
from ids.
If @pasi-paasiala 's proposal is agreeable, which I support, just merge PR #149.
from ids.
Why is the interpretation vague? There are clear examples here https://github.com/buildingSMART/IDS/blob/master/Documentation/testcases-ids.md and the meaning seems clear to me https://github.com/buildingSMART/IDS/blob/master/Documentation/developer-guide.md#optionality
from ids.
Vagueness
Why is the interpretation vague?
Does an optional requirement on an optional attribute specify anything beyond what is already defined in the IFC schema itself? Can it be safely ignored without worry to invalidate the result of a check? What if the value is not Foobar as defined in the requirement, but Barfoo? Should that fail the check?
Examples
All of the referenced examples use:
which is not according to the referenced specification:
What was the originating intention? I believe these should be addressed in #148 (or other PR) as well.
from ids.
I believe these should be addressed in #148 (or other PR) as well.
I try to keep the development files up to date with the schema.
Once this change is accepted I will produce a PR for those files.
from ids.
The testcases need updating, but I think the intention is spelled out already:
Also notably, the occurs can be used to set prohibited. So you can say "This entity shall not have this attribute filled out".
from ids.
Presumably the integration test case data using attribute facets also need amending? i.e those IDS files at https://github.com/buildingSMART/IDS/tree/master/Documentation/testcases/attribute
from ids.
Hi @andyward,
they absolutely do, but right now they are generated programmatically from code in a different repository.
AFAIK only @Moult can do that.
Claudio
from ids.
Also notably, the occurs can be used to set prohibited. So you can say "This entity shall not have this attribute filled out".
I don't think we encountered this requirement in any of the use cases.
from ids.
Also notably, the occurs can be used to set prohibited. So you can say "This entity shall not have this attribute filled out".
I don't think we encountered this requirement in any of the use cases.
The discussion on prohibited came fairly late. I can't reconstruct it entirely either, but I think it makes sense to be consistent here. If we want to enable forbidding certain entity usage, certain property usage, we can also prohibit attribute usage.
It makes sense that the use cases we have focus on what they need and not what they do not need. But the act of forbidding a certain attribute constructs can be very informative, such as: "IfcSite.RefLatitude should not be used, rather use IfcMapConversion".
So for me, setting maxoccurs=0 (prohibited) or minoccurs=1 (required) on an optional attribute makes sense.
facet specification with minoccurs=0 (optional) is a general recurring topic, we apparently had the desire to make optional statements: "if the tool has this data please provide it here".
For me this warrants maintaining the attribute occurs constraint as we have it, but I agree there is more effort needed in spelling out all the implications, because I agree the majority of permutations of attribute types and occurrence constraints are pure noise. But that's the consequence of the choice we made to model prohibited/optional using integers.
from ids.
TLDR: We need to discuss whether to bring back <xs:attributeGroup ref="xs:occurs"/>
for attributes
Long:
Your argument makes sense to me. We might have jumped the gun writing the PR.
In fairness, even if I don't necessarily subscribe to it, the main argument held throughout the development was the prominence of documented use cases.
But that's the consequence of the choice we made to model prohibited/optional using integers.
Indeed... the original sin! ;-)
It would be nice to resume a regular meeting to bring IDS to a robust 1.0 in the medium short time-frame. It could be the right venue to come to sound decisions on the closure of issues and merging of PRs.
from ids.
Any updates on this?
from ids.
The preliminary agreement on the call was as follows:
Document that cardinality applies to the value, not the existence of the attribute itself in the model.
Agreement is to bring back the attribute cardinality to express the possibility of prohibiting values.
Also document with at least one test case.
This will require a schema change. 0.9.7 in dev.
However, the conversation moved to a bigger issue of the interpretation of the cardinality on specification, that we need to close before we make any progress here. See #203
from ids.
Added to the schema changes presented in the call on 2024-02-02
from ids.
Related Issues (20)
- List of datatypes with Enum types used by attributes HOT 6
- List of datatypes without IfcCompoundPlaneAngleMeasure HOT 2
- IfcLogical representation in XML base HOT 1
- IMPROVEMENT: functionality to point towards bSDD (data dictionaries) HOT 4
- IDS BIM
- Restriction of values: Enumeration limited to string-based datatype or do we allow for real, integer and measurements HOT 3
- Predefined type evaluation
- userdefuned HOT 6
- Test case naming consistency HOT 2
- 2 testcases have .html file instead of .ifc HOT 2
- Tolerance documentation 1.0.0 HOT 6
- Wrong file name in the entity directory of test cases HOT 1
- Tolerance test issues in 1.0 HOT 3
- Are complex restrictions applicable to all facet parameters? HOT 2
- Test case for indirect containment is incorrect
- Relation between enumerations in Applicability and Requirements HOT 1
- Broken links on dev Readme HOT 1
- Add textual definitions to each IDS element HOT 1
- IfcTester check ifc version?
- Proposal: Permit dataType equivalents for non-measure Property values HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ids.