Coder Social home page Coder Social logo

Comments (14)

Moult avatar Moult commented on July 25, 2024 1

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.

CBenghi avatar CBenghi commented on July 25, 2024

If @pasi-paasiala 's proposal is agreeable, which I support, just merge PR #149.

from ids.

Moult avatar Moult commented on July 25, 2024

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.

pjanck avatar pjanck commented on July 25, 2024

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:

grafik

which is not according to the referenced specification:

grafik

What was the originating intention? I believe these should be addressed in #148 (or other PR) as well.

from ids.

CBenghi avatar CBenghi commented on July 25, 2024

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.

Moult avatar Moult commented on July 25, 2024

The testcases need updating, but I think the intention is spelled out already:

https://github.com/buildingSMART/IDS/blob/master/Documentation/testcases-ids.md#pass-specification-optionality-and-facet-optionality-can-be-combined

https://github.com/buildingSMART/IDS/blob/master/Documentation/testcases-ids.md#pass-a-prohibited-specification-and-a-prohibited-facet-results-in-a-double-negative

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.

andyward avatar andyward commented on July 25, 2024

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.

CBenghi avatar CBenghi commented on July 25, 2024

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.

CBenghi avatar CBenghi commented on July 25, 2024

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.

aothms avatar aothms commented on July 25, 2024

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.

CBenghi avatar CBenghi commented on July 25, 2024

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.

Andrej730 avatar Andrej730 commented on July 25, 2024

Any updates on this?

from ids.

CBenghi avatar CBenghi commented on July 25, 2024

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.

CBenghi avatar CBenghi commented on July 25, 2024

Added to the schema changes presented in the call on 2024-02-02

from ids.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.