Computer interpretable (XML) standard to define Information Delivery Specifications for BIM (mainly used for IFC)
License: Other
Proposal for the definition of specification.use:
The "use" of a "specification" declares the requirement for the specification (checking rule) itself. The possible values have the following meaning:
Is this our common understanding?
Hello all,
I was wondering where we stand when it comes to case sensitivity matching strings.
An 'xs:pattern' on a property name should probably be case sensitive, but what if somebody sets the a
patter constraint for IFCWALL vs. IFCwall? I would argue that against schema parts (i.e. types, predefined types, class attributes...)
a user might reasonably expect some freedom.
Should we vote on this?
Also, I think that we should start documenting these decisions in the repository.
Best,
Claudio
With all the regular expressions everywhere, I think it would be good if you could also add a description in human language to each regex that describes what is being done. For example if we are checking a specific naming convention for product names with a regex like this:
[a-z]{3}-[a-z]{3}-[a-z]{3}-[a-z]{1,15}[a-z]{2}What error message are you going to be able to show that a regular (no pun intended) user would actually comprehend?
Hello,
If I read the schema correctly, the introduction of partOf in 9f85b90 seems to break the symmetry of facets between applicability and requirement.
IDS/Development/0.5/ids_05.xsd
Lines 192 to 210 in 9f85b90
I don't have a strong opposition to this, but my spider sense goes tingling to the roof whenever something like this happens.
What is the point of excluding this feature (if useful) from applicability?
I though symmetry of facets was an important aspect of IDS.
IDS/Development/0.5/ids_05.xsd
Line 6 in 80af13f
As far as I understand it it should just be used for namespace declaration but should not be imported.
See: https://www.w3.org/2001/XMLSchema-instance
Removing the import line allows validating for example: https://github.com/buildingSMART/IDS/blob/master/Development/0.5/IDS_ucms_prefab_pipes_IFC4.3.xml
With the import it fails on parsing schema.
Hello,
Is there a document where I may read about the aim of this format?
I'm particularly interested in its scope.
I assume that checks that go beyond information availability are (at least at this stage) out of scope.
But, are we expecting that there should be methods for specifying model completeness?
I'm thinking for example of rules such as:
Thanks,
Claudio
Currently the xs:pattern is used to define regular expressions in several values.
However, this flavour of regex is limited. See https://www.regular-expressions.info/xml.html
Many of the examples rely on a richer flavour of regex.
Other flavours of regex are often restricted to specific programming languages. It is not trivial to implement a Javascript regex flavour in other programming languages.
The .NET regex patterns are most used in our industry, and seem compatible with the Perl5 regex language.
Should we choose one? Which one?
Or should we choose one with some limitations to make it compatible with more languages (python seems important these days)?
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
I suppose that the intended content of info was a sequence, instead of the stated choice.
IDS/Development/Third production release/ids.xsd
Lines 9 to 19 in 2c95ab1
If that's the case, I've prepared PR #9 to fix the xsd.
IfcMeasure element is now added to properties (please review).
There are a couple of comments and open questions:
For example IfcAreaMeasure is defined as being given in square meters (m2) in the IDS (defined on https://github.com/buildingSMART/IDS/wiki/Physical-Quantities-and-Units).
For the value in the property value element it means restrictions need to be in m2. For example a pipe needs to have a value between 2 and 6 square meters.
This means the restrictions need to be addressed as:
<xs:restriction base="xs:integer">
<xs:minInclusive value="2"/>
<xs:maxInclusive value="6"/>
</xs:restriction>
The minInclusive and MaxInclusive are defined by the 'base' attribute in the xs:restriction element. In this example set as 'integer'.
What is the implication of the value of this 'base' element for using fixed physical quantities and units?
Looking at the recently published v0.4, I was wondering how to encode the check for the "existence of a property". That is, how to check that "FireRating" property is specified, however, its value is not of concern?
IDS/Development/0.4/ids_04.xsd
Line 55 in 4657203
The XSD converter from Microsoft complains that ref="xs:restriction" is not defined.
I tried correcting to type="xs:restriction" (guessing here that this was what was meant), the attribute still needs a name. What would that be?
Hello,
We have a working implementation of IDS version 0.5, but I'm having trouble to understand the following lines.
IDS/Development/0.5/IDS_random_example_04.xml
Lines 12 to 18 in 7903eae
Is this by design?
Thanks,
Claudio
See readme.md
I would like to re-open the question of how we represent
b. Selections (“ I want glazing-percentage recorded on all IfcDoors, IfcWindows and Grilles!”)
Originally posted by @NickNisbet in #13 (comment)
I would like to re-open the question of how we represent
a. Exceptions (“I want weight recorded on all objects except ifcOpeningElement and ifcSpace!”)
Originally posted by @NickNisbet in #13 (comment)
Some hints about ids schema 0.5.10, possibly to be checked:
Hello all,
we have prepared a web interface for filling in IDS schemas updated to the latest version v0.5
You can test it at https://www.xbim.it/xids?bs=true
This is a web assembly application that is running entirely in your browser, and no information is exchanged with our server.
You can however save the information to XML for your purposes (and load it back for editing via drag-drop).
Any feedback is welcome.
Best,
Claudio
Hi folks,
the attribute type does not mandate a value, it is optional.
If we leave it empty:
The IFC schema in this case is different from the property case. For properties we can check that an instance of IfcPropertySingleValue (instance containing the value) exists or not, whereas here the containing instance always exist (it's the entity we are checking itself).
For conceptual symmetry (and implementation reuse) I would prefer option 1, but then I'd probably have a conversation to see if
it makes sense to mark the value required.
An empty value, would just be a different way to identify a set of entities by type.
Claudio
Seeing the example IDS_aachen_example.xml it seems that there is a keyword "attribute" for checking an attribute instead of property (I would normally expect that "attribute" should be the name of IfcPropertySet.Name).
Is there a documentation about such implicit agreements or keywords?
Extract from mentioned example:
<ids:requirements>
<ids:property location="instance">
<ids:propertyset>
<ids:simpleValue>attribute</ids:simpleValue>
</ids:propertyset>
<ids:name>
<ids:simpleValue>name</ids:simpleValue>
</ids:name>
<ids:value>
<xs:restriction>
<xs:pattern value="^(Wanddurchbruch.*|Deckendurchbruch.*)" />
</xs:restriction>
</ids:value>
</ids:property>
</ids:requirements>
Hello,
I'm not quite sure how to interpret the location clause for an attribute type.
IDS/Development/0.5/ids_05.xsd
Lines 178 to 186 in ffbd396
I hope I get it right that this facet points, for instance, to an IfcWindow.OverallHeight.
If that's the case what does it mean to be specified at "type" level?
IfcWindowType does not have that attribute, of course.
Is this just an oversight?
Thanks,
Claudio
We have discussed in the call options to enforce the location of properties (i.e. entity vs. type level).
The rationale to enforce type level storage could be:
Complexity of the implementation will have to consider:
When trying to generate Java classes from the XSD, I had to remove line 7 from the XSD. I don't think it is required.
Anyone with more experience in XSD/XML known why it is there?
<xs:import namespace="http://www.w3.org/2001/XMLSchema-instance" schemaLocation="http://www.w3.org/2001/XMLSchema-instance"/>Hi, I noticed the ids_05.xsd from a few days ago is missing the xml header. Since some xsd viewers cannot open the file without it, I thought to let you know.
Cheers
Background
These ideas are non-proprietary and in the public domain since 2007. They have been used in ISO12911:2010 onwards and so are free of copyright and IP. They are already embedded in mvdXML. They are logically complete and sufficient in the strict, mathematical sense.
see • Nisbet N, Wix J and Conover D. 2008. "The future of virtual construction and regulation checking”, in Brandon, P., Kocaturk, T. (Eds),Virtual Futures for Design, Construction and Procurement, Blackwell, Oxfordshire. doi: 10.1002/9781444302349.ch17 .
Use cases
The current proposal is very likely to be inadequate.
Its assumes a simple :
"if A1 then R1 R2" form, where A1 is the applicability and R1 and R2 are requirements.
However
a. There may be many serial applicabilities A1, A2 ..., each narrowing the scope, for example "external" "opening"
b. There may be many parallel selections, S1, S2 ..., each broadening the scope, for example "door" "window" "louvre"
c. There may be exceptions, E1, E2 ... escaping the rule, for example "tropical" "temporary structure"
d. Yes, there may well be multiple requirements R1, R2 ..., for example "waterproof" "windproof"
The following ideas were developed to make sure that rules can be BOTH human-readable AND machine readable.
These ideas are required in any situation other than the simplest . They allow the condensing of what otherwise have to be long, repetitive and error prone tables (see any buildingSMART spreadsheet MVD) into the most concise and unambiguous form possible.
Recommendation 1: A syntax should be used which accepts these.
Syntax:
Objective1 :=[ 1:4] Applicabilities &| Selections &| Exceptions &| Requirements (contain one upto 4 of)
Applicabilities | Selections | Exceptions | Requirements := [1:n] Metrics (contain one or more of)
Outline:
Objective {
Applicabilities {
Metric1,
Metric2
}
Selections {
Metric3,
Metric4
}
Exceptions {
Metric5,
Metric6
}
Requirements {
Metric7,
Metric8
}
}
Just to reassure you, the simple form is still simple!
Objective {
Applicabilities {
Metric1
}
Requirements {
Metrict7
}
}
Note on Terms:
'Objective' is synonymous with 'Rule'
'Metric' is synonymous with 'Test'
BUT Requirements is used much more specifically here compared to the previously posted proposal.
Recommendation 2: The syntax for the applicability, selection, exception and requirement Metrics should be identical.
Syntax:
Metric1 := Entity X | Property X | (more)
Example: Any window should have its light transmittance documented
Objective { Applicabilities { Entity IfcWindow } {Requirements { Property LightTransmittance }}
Example: Light transmittance should only be used on windows.
Objective { Applicabilities { Property LightTransmittance } {Requirements { Entity IfcWindow }}
More thought can be given to the number of different kinds of metrics we wish to support, including Level of detail and symbology.
Syntax:
Metric1 := Entity X | Property X | **Representation X** | (more)
Recommendation 3: The syntax in rule 2 should also include 'Objective' .
Syntax:
Metric1 := Entity X | Property X | Objective | (more)
This supports the recursive nature of plain language, meaning that ANY requirement document can be captured, including all existing MVDs. Any plain language document using any layout or language, using passive or active grammar, using simple or complex sentences, using normative or descriptive wording, can be expressed,
Recommendation 4: Make an explicit one-to-one mapping to IfcObjective and IfcMetric
The IfcConstraint model is already sufficient to do 'IDS' even if the step, ifcxml or ifcjson representations are wordy or obscure. But this means that any application that can read IFC can additionally read IDS without any further interface development.
Recommendation 5: Consider not needing IDS json or xml at all, just HTML with 'RASE' mark-up.
"All external doors windows and louvres shall have properties waterproof and windproof except in the tropics or in temporary structures."
This use of HTML also allows us to use tables of requirements efficiently. ( Github doesn't let me show how).
Hello @berlotti,
reading through the examples I don't understand if they are to be considered alternative ideas or both valid.
Suggests the intention to use json-schema itself to specify the requirements, whereas
is an independent format.
Because the implementation screenshot uses the second I'm inclined to think that this would be the preferred plan.
Could you clarify if they are intended to coexist?
Thanks,
Claudio
Have you considered using XSD 1.1 instead of 1.0? 1.1 gives more control over restrictions with the assertions, it has built-in enumeration alternatives, and maybe less helpful in our case global attributes. I don't have experience with it, but according to the StackOverflow it solves the negation problem we were discussing on Tuesday.
https://www.altova.com/blog/what-s-new-in-xml-schema-11/
https://stackoverflow.com/questions/37563199/xml-schema-restriction-pattern-for-not-allowing-specific-string
http://www.datypic.com/books/defxmlschema/chapter14.html
The "use" attribute in requirements definitions is optional. If given, it is allowed to be either "required" or "optional" (see extract below).
If the use attribute is not given, what is the interpretation of this requirement then?
Extract from latest spec:
<xs:complexType name="requirementsType">
<xs:sequence maxOccurs="unbounded">
..
<xs:element name="property" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:complexContent>
<xs:extension base="ids:propertyType">
..
<xs:attribute name="uri" type="xs:anyURI" use="optional"/>
<xs:attribute name="use" use="optional">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="required"/>
<xs:enumeration value="optional"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
Hello
There are two elements in the example schema with the same name but different structure.
I would suggest that the naming property should not be repeated for elements at lines 80 and 82
IDS/Development/First production release/Examples.md
Lines 80 to 82 in d86f4a5
If might be an idea to make this invalid in the schema as well.
A more stylistic point regards the arrangement of the basic elements: We propose to put the info element on top of the xml. From our point of view info element has a header character, so it belongs to the top.
And we propose to bind together the specification elements in a collection list with a specifications (with -s!) element. In our experience is more common model style in xml files as an "open" list mixed with other xml elements (info and introductions).
So, the xml structure would look like this:
<ids …>
<info … />
<specifications>
<specification … />
…
<specification … />
</specifications>
<instructions … />
</ids>
Instead of IDS 0.4.2:
<ids …>
<specification … />
…
<specification … />
<instructions … />
<info … />
</ids>
Since #15 was prematurely closed, I'm opening a new issue to raise my concerns:
IDS/Development/0.4/ids_04.xsd
Line 55 in 4657203
I did some digging here:
xs:restriction is a built-in data type of the namespace xs not an element, right? Therefore it should be type and not ref in my opinion.
For more clearness and transparency we suggest a more explicit notation: We propose - without treat new concepts – a separate attribute and quantity element. Especially the actual attribute approach, we think, it’s inappropriate to modelling an attribute in form of a property (with the propertyset name "attribute") as suggested. This "secret code" is not transparent, and we avoid the approach that content controls the model structure. It could be a pragmatic approach in an established structure which is difficult to change but not in a new draft.
It could take a long time till IFC 5 is established. We think it is justified to use a concept for the moment that can be easily changed later.
We propose an independent attribute element which is very near to the property element. Our proposal is this quite analog to the property element:
<ids:attribute location="…" uri="…" use="…">
<ids:name … />
<ids:value … />
</ids:attribute>
In the same sense an additional and independent quantity element:
<ids:quantity location="…" uri="…" use="…">
<ids:quantityset>
<ids:simpleValue>...</ids:simpleValue>|<xs:restriction>...</xs:restriction>
</ids:quantityset>
<ids:name … />
<ids:value … />
</ids:quantity>
Suggested changes to the info element:
In the info element the version element shouldn’t be decimal. E.g. version name '0.4.2' is not decimal compatible.
We prefer none of the elements are required (-> minOccurs="0") except the ifcversion element. Especially the copyright element shouldn’t be required. Copyright is an organizational/juridical/contractual question which shouldn’t be given by a technical specification.
The author element shouldn’t make any restriction, especially no constriction to email address.
Hello,
is the use of the xs: namespace intentional in the example below?
IDS/Development/First production release/Examples.md
Lines 84 to 88 in d86f4a5
I guess this is a station well passed, but anyways.
Now I often have two very similar files for what is logically the same check:
To avoid creating and maintaining many duplicates of IDS specifications, would it not make more sense to allow the IDS writer to (optionally) specify multiple IFC schemas that the IDS works for? Also when validating a model, it saves the user the headache of selecting the correct version of the IDS. Adding this option would also still allow highly schema-version specific IDS checks to be created as multiple different XMLs with each only 1 ifcVersion.
So now you would have:
Another option could be to add the ability to store multiple IDS specs in one XML file, each with a different IFC schema. This way the validating software can automatically select the applicable IDS (because it already knows the schema of the IFC to be validated). This way you can distribute IDS specification by sending back and forth just one XML file and it is clear that logically the different contained specs are supposed to be equal (just different IFC schemas).
So now you would have:
Proposal for discussion after meeting 2022-02-22:
prerequsites
definitions for use:
The example defines a pattern for an entity selection. The pattern "IfcCovering" is combined with a minExclusive setting.
What is the meaning of this restriction?
<ids:applicability>
<ids:entity>
<ids:name>
<xs:restriction>
<xs:pattern value="IfcCovering" />
<xs:minExclusive value="1" /> <!-- combination of multiple restrictions possible -->
</xs:restriction>
</ids:name>
<ids:predefinedtype>
<ids:simpleValue>CLADDING</ids:simpleValue>
</ids:predefinedtype>
</ids:entity>
</ids:applicability>
Are the values in the xml nodes case sensitive or not?
Or should we add an attribute to define case sensitivity? Per node or per IDS?
Currently IDS has the applicability phase where we select objects to check and the requirements phase where those objects are being checked. The nice thing about this is that when working with the results, you know which objects were checked, and which of those failed and which succeeded. Currently all results are based on the individual objects either passing or failing.
There are also use cases where one would like to put constraints on the amount of objects that failed or passed.
Can not use certain entities
A typical requirement is to say that for example IfcBuildingProxyObject cannot be used at all. The applicability could be set to Entity IfcBuildingProxyObject, but there is no way to say that when at least one results comes up, it's a failure.
Must use certain entities
You can imagine that at least one IfcProject, one IfcSite and one IfcBuilding and perhaps one IfcBuildingStorey must be in the model. Some of these would obviously not even pass the IfcSchema validation, but others would.
Properties on IfcProject
You can imagine the need to check certain properties to exist on the IfcProject entity. You would probably put an Entity applicability on IfcProject and then a few properties in the requirements. But what if there is no IfcProject in the model at all? Would that mean it's valid? No it would not, and you should be able to indicate this in the IDS itself.
To extend the 2 existing phases with a 3rd (optional) phase: Consolidation (there is probably a better word for it). It can have multiple success or multiple error tags, but no mix of the two.
<consolidation>
<success phase="applicability | requirements" when="NO_RESULTS | EXACTLY_ONE_RESULT | AT_LEAST_ONE_RESULT | MORE_THAN_ONE_RESULT" />
<error phase="applicability | requirements" when="NO_RESULTS | EXACTLY_ONE_RESULT | AT_LEAST_ONE_RESULT | MORE_THAN_ONE_RESULT" />
</consolidation>The idea is that this allows you to define what makes a single IDS specification fail or succeed. Assuming that the second phase (requirements) returns all objects that failed the requirements, the default would be:
<consolidation>
<success phase="requirements" when="NO_RESULTS" />
</consolidation>Example 1
Only the applicability phase is needed, and it cannot have any results. You can also define this check with an applicability of "all objects" and then add an entity requirement of IfcBuildingElementProxy (in that case the phase needs to be "requirements".
<consolidation>
<success phase="applicability" when="NO_RESULTS" />
</consolidation>Example 2
Assuming that one specification is created for each entity that needs to be checked. No requirements are needed for this check, and the applicability phase should result in at least one (or exactly one for some) result.
<consolidation>
<success phase="applicability" when="AT_LEAST_ONE_RESULT" />
</consolidation>Example 3
There must be exactly one IfcProject (applicability phase should result in 1 object), and there can be no results (failures) of the requirements phase:
<consolidation>
<success phase="applicability" when="EXACTLY_ONE_RESULT" />
<success phase="requirements" when="NO_RESULTS" />
</consolidation>Hello @berlotti,
I've spent a little time filling in the remaining dimensional exponents in the table from the wiki...
because I haven't got write permissions in the wiki, I'm pasting the markdown code here.
I hope it helps.
| Physical Quantity (unique name to be used in IDS) | Unit | Unit Symbol | Ifc Measure | dimensional exponents | QUDT |
|---|---|---|---|---|---|
| Amount of substance | mole | mol | IfcAmountOfSubstanceMeasure | (0, 0, 0, 0, 0, 1, 0) | |
| Area density | Kg/m2 | IfcAreaDensityMeasure | (-2, 1, 0, 0, 0, 0, 0) | quantitykind:MassPerArea | |
| Area | square meter | m2 | IfcAreaMeasure | (2, 0, 0, 0, 0, 0, 0) | quantitykind:Area |
| Dynamic viscosity | Pa s | IfcDynamicViscosityMeasure | (-1, 1, -1, 0, 0, 0, 0) | quantitykind:DynamicViscosity | |
| Electric capacitance | farad | F | IfcElectricCapacitanceMeasure | (-2, 1, 4, 1, 0, 0, 0) | quantitykind:Capacitance |
| Electric charge | coulomb | C | IfcElectricChargeMeasure | (0, 0, 1, 1, 0, 0, 0) | quantitykind:ElectricCharge |
| Electric conductance | siemens | S | IfcElectricConductanceMeasure | (-2, -1, 3, 2, 0, 0, 0) | quantitykind:ElectricConductivity |
| Electric current | ampere | A | IfcElectricCurrentMeasure | (0, 0, 0, 1, 0, 0, 0) | quantitykind:ElectricCurrent |
| Electric resistance | ohm | Ω | IfcElectricResistanceMeasure | (2, 1, -3, -2, 0, 0, 0) | quantitykind:Resistance |
| Electric voltage | volt | V | IfcElectricVoltageMeasure | (2, 1, -3, -1, 0, 0, 0) | quantitykind:Voltage |
| Energy | joule | J | IfcEnergyMeasure | (2, 1, -2, 0, 0, 0, 0) | quantitykind:Energy |
| Force | newton | N | IfcForceMeasure | (1, 1, -2, 0, 0, 0, 0) | quantitykind:Force |
| Frequency | hertz | Hz | IfcFrequencyMeasure | (0, 0, -1, 0, 0, 0, 0) | quantitykind:Frequency |
| Heat flux density | W/m2 | IfcHeatFluxDensityMeasure | (0, 1, -3, 0, 0, 0, 0) | quantitykind:HeatFluxDensity | |
| Heating | J/K | IfcHeatingValueMeasure | (2, 1, -2, 0, -1, 0, 0) | quantitykind:HeatCapacity | |
| Illuminance | lux | lx | IfcIlluminanceMeasure | (-2, 0, 0, 0, 0, 0, 1) | quantitykind:Illuminance |
| Ion concentration measure | Kg/m3 | IfcIonConcentrationMeasure | (-3, 1, 0, 0, 0, 0, 0) | quantitykind:IonDensity | |
| Iso thermal moisture capacity | m3/Kg | IfcIsothermalMoistureCapacityMeasure | (3, -1, 0, 0, 0, 0, 0) | ||
| Length | meter | m | IfcLengthMeasure | (1, 0, 0, 0, 0, 0, 0) | quantitykind:Length |
| Speed | m/s | IfcLinearVelocityMeasure | (1, 0, -1, 0, 0, 0, 0) | quantitykind:Speed | |
| Luminous flux | Lumen | lm | IfcLuminousFluxMeasure | (0, 0, 0, 0, 0, 0, 1) | quantitykind:LuminousFlux |
| Luminous intensity | candela | cd | IfcLuminousIntensityMeasure | (0, 0, 0, 0, 0, 0, 1) | quantitykind:LuminousIntensity |
| Mass density | Kg/m3 | IfcMassDensityMeasure | (-3, 1, 0, 0, 0, 0, 0) | quantitykind:MassDensity | |
| Mass flow rate | Kg/s | IfcMassFlowRateMeasure | (0, 1, -1, 0, 0, 0, 0) | quantitykind:MassFlowRate | |
| Mass | kilogram | Kg | IfcMassMeasure | (0, 1, 0, 0, 0, 0, 0) | quantitykind:Mass |
| Mass per length | Kg/m | IfcMassPerLengthMeasure | (-1, 1, 0, 0, 0, 0, 0) | quantitykind:MassPerLength | |
| Modulus of elasticity | N/m2 | IfcModulusOfElasticityMeasure | (-1, 1, -2, 0, 0, 0, 0) | quantitykind:ModulusOfElasticity | |
| Moisture diffusivity | m3/s | IfcMoistureDiffusivityMeasure | (3, 0, -1, 0, 0, 0, 0) | ||
| Molecular weight | Kg/mol | IfcMolecularWeightMeasure | (0, 1, 0, 0, 0, -1, 0) | quantitykind:MolarMass | |
| Moment of inertia | m4 | IfcMomentOfInertiaMeasure | (4, 0, 0, 0, 0, 0, 0) | quantitykind:MomentOfInertia | |
| PH | PH | IfcPHMeasure | (0, 0, 0, 0, 0, 0, 0) | ||
| Planar force | Pa | IfcPlanarForceMeasure | (-1, 1, -2, 0, 0, 0, 0) | quantitykind:ForcePerArea | |
| Angle | radian | rad | IfcPlaneAngleMeasure | (0, 0, 0, 0, 0, 0, 0) | quantitykind:Angle |
| Plane angle | radian | rad | IfcPlaneAngleMeasure | (0, 0, 0, 0, 0, 0, 0) | quantitykind:PlaneAngle |
| Power | watt | W | IfcPowerMeasure | (2, 1, -3, 0, 0, 0, 0 | quantitykind:Power |
| Pressure | pascal | Pa | IfcPressureMeasure | (-1, 1, -2, 0, 0, 0, 0) | quantitykind:Pressure |
| Radio activity | Becqurel | Bq | IfcRadioActivityMeasure | (0, 0, -1, 0, 0, 0, 0) | quantitykind:Activity |
| Ratio | Percent | % | IfcRatioMeasure | (0, 0, 0, 0, 0, 0, 0) | quantitykind:DimensionlessRatio |
| Rotational frequency | hertz | Hz | IfcRotationalFrequencyMeasure | (0, 0, -1, 0, 0, 0, 0) | |
| Section modulus | m3 | IfcSectionModulusMeasure | (3, 0, 0, 0, 0, 0, 0) | quantitykind:SectionModulus | |
| Sound power | decibel | db | IfcSoundPowerMeasure | (0, 0, 0, 0, 0, 0, 0) | quantitykind:SoundPowerLevel |
| Sound pressure | decibel | db | IfcSoundPressureMeasure | (0, 0, 0, 0, 0, 0, 0) | quantitykind:SoundPressure |
| Specific heat capacity | J/Kg K | IfcSpecificHeatCapacityMeasure | (2, 0, -2, 0, -1, 0, 0) | quantitykind:SpecificHeatCapacity | |
| Temperature rate of change | K/s | IfcTemperatureRateOfChangeMeasure | (0, 0, -1, 0, 1, 0, 0) | quantitykind:TemperaturePerTime | |
| Thermal conductivity | W/m K | IfcThermalConductivityMeasure | (1, 1, -3, 0, -1, 0, 0) | quantitykind:ThermalConductivity | |
| Temperature | kelvin | K | IfcThermodynamicTemperatureMeasure | (0, 0, 0, 0, 1, 0, 0) | quantitykind:ThermodynamicTemperature |
| Time | second | s | IfcTimeMeasure | (0, 0, 1, 0, 0, 0, 0) | quantitykind:Time |
| Torque | N m | IfcTorqueMeasure | (2, 1, -2, 0, 0, 0, 0) | quantitykind:Torque | |
| Vapor permeability | Kg / s m Pa | IfcVaporPermeabilityMeasure | (0, 0, 1, 0, 0, 0, 0) | ||
| Volume | cubic meter | m3 | IfcVolumeMeasure | (3, 0, 0, 0, 0, 0, 0) | quantitykind:Volume |
| Volumetric flow rate | m3/s | IfcVolumetricFlowRateMeasure | (3, 0, -1, 0, 0, 0, 0) | quantitykind:VolumeFlowRate |
There are different kinds of material definitions in IFC (single material, material layers, material constituent, material profile). Material requirements in IDS define a single value only.
How to implement checking of material requirements?
Is it focused on single material only, and checking of the IfcMaterial.Name attribute?
If checking existance of properties I normally do not care if it is attached to the occurrence (IfcObject) or type (IfcTypeObject).
If restricting the requirements to "type" does it automatically mean that this information shall not be available on the occurrence level?
In the latest schema minOccurs and maxOccurs are defined as integers and we're not reusing the xs namespace objects.
in the xs namespace they are not strictly integer, though, as maxOccurs can be unbounded.
In any case we have to define the default value when the attributes are not defined in the files. In the xs namespace their default is 1.
If this is the case, we have also to change sample files to set maxOccurs to 'unbounded' where minOccurs is "1".
Finally, they type should be a nonNegativeInteger instead of Integer.
maxOccurs = (nonNegativeInteger | unbounded) : 1
minOccurs = nonNegativeInteger : 1
Hi,
I see that entity are required in the definition of applicability, while the others (classification, property and material) all have minOccurs="0"
IDS/Development/Third production release/ids.xsd
Lines 66 to 68 in 2c95ab1
I know of IDSs that are classification based, rather than entity based. In those scenarios the current schema would force us to repeat the classification requirement for all possible types, resulting in very large IDS files.
I would suggest that entity is also marked-up with minOccurs="0".
Can I ask what is the benefit of forcing the declaration of entity?
Hello all,
in the IDS call (i think it was the 5th of April) we were still discussing pros/cons of the changes introduced with 960951e (the use of min/max occurs instead of the enum).
In the call there was no one knowing of use cases with the need of specifying a precise number of elements (e.g. 4 doors).
The previous enum (prohibited, required, optional) for applicability felt complete and more extensible in the long run than min/max occurrence.
Should we revert that commit?
Sentence starts, but does not finish.
Line 61 in 4657203
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 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.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
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.