Restrictions on name attributes

[fkleedorfer]

I know there is a restriction not to use the prefix "Pset_" for user defined property sets. Are there any other restrictions on names of property sets, properties etc?

The standard uses Pascal Case for PropertySets, using only the characters matching the regex [a-zA-Z_]. Is this to imply that user defined names MUST or SHOULD follow this style? Or, alternatively, is it permissible to use any technically allowed character sequence, except "Pset_" at the start of a property set name?

[aothms]

That's a great question. I only have some random thoughts on this subject:

I couldn't find anything written in the specification. Due to the generic nature of IFC and the fact that we're reusing Name: IfcLabel for what is basically an identifier is in that light somewhat problematic.

IFC is an international standard so we have to consider that non-ascii use is probably valid. Backwards compatibility is highly considered, so even documentation changes constraining the use of attributes allowed in previous editions of the spec could be considered as prohibitive.

In IDS it's possible to provide a regex patterns specifically for property set names if you were so inclined.

There is a rule in the validation service (validate.buildingsmart.org) that checks that property set names with a Pset_ prefix conform to the list of predefined names. https://github.com/buildingSMART/ifc-gherkin-rules/blob/main/features/PSE001_Standard-properties-and-property-sets-validation.feature

There is talks about extending that to other variations and permutations of pset in different cases and different separators.

Other than that, I'd say to apply common sense when naming thing.

[TLiebich]

just to confirm @aothms statement - the Name attribute in IFC allows for unicode characters, i.e. "that any character from ISO 10646 may occur in a string" - so I would assume that also IDS has to allow it as well, since property (set) names can be provided in local languages.

[Moult]

I totally recommend using emojis as much as possible.

[Extender-BIM]

To give u some context:
Currently we are looking to define do´s and don’ts for project driven Data structure development in BIM.
One Aspect is the naming of the attached information. Starting by the Property and ending by Enumeration values.

1. Property Sets
   Property Sets in the IFC Standard are always represented in Pascal Case (upper camel case), just the special character "__" ist used in the Prefix "Pset_" to identify the Property sets defined in the ISO standard. Commonly it is now used to define Company Specific property sets with a Prefix of the Company FCP_ for example.
   In IFC4.3 IfcPropertySet has as IfcRoot.Name as IfcLabel --> label defined in ISO 10303-41 --> String 255 char, therefore it is Possible to define a lot of special characters with different Problems in usage.
   --> It would be possible by definition to use mathematical operators inkl. ( )
   Software which have the possibilities to use Formulas have the problem to identify Parameters because it sees them as independent parameters to be calculated with.
   For example “FCP_MEP-electric” (fictive) Formula interpretation "FCP_MEP" - "electric"
   --> It would be possible to use “.” And “:” “;” etc.
   In a lot of Documentation's of tools “.” will be used as delimiter between Pset and Property Namings for identification purposes. It would mess up the system. Same for “:”
   “;” can mess up List representation and codes

Simply it is easier to Work with a project if the Data structure is set up in a manner that already considers this problems.

Easiest definition would be the complete Avoidance of special character. But this has to be well defined.
In Austria for example we have special letters like “ä, ü, ö, ß” they can be described as “ae” “ue” “oe” “sz” but it will get exponentially harder to read. IFC has no problem with this character because they will be converted to utf-8 “ä” will be “\X\E4”

A List of Not useable letters or conventions would be nice.

As Example: No Mathematical Operations or Symbols and punctuation
Exclude all of this for Namings:
! " # $ % & ' ( ) * + - . , / : ; < = > ? [ \ ] ^ { | } ~ ¡ ¢ £ ¤ ¥ ¦ § ¨ © ª « ¬ ® ¯ × ÷ ` @
I never had a Problem with Space in naming maybe this can be allowed
The only exception is “_” as Seperator of a Prefix of a Naming convention (Pset or company name etc.)
Like a Mixture of Pascal Case and Snake Case maybe allowing Spaces

2. Properties same Problems but defined as IfcIdentifier - identifier defined in ISO 10303-41 --> STRING of up to 255 char
3. Text Properties or Lables - can lead to same problems if used in filters, can be

• IfcText - text defined in ISO 10303-41 - STRING (almost no limitation)
• IfcLabel - label defined in ISO 10303-41 - STRING of up to 255 characters

[aothms]

Maybe you could phrase that as a series of allowed unicode categories (https://www.compart.com/en/unicode/category) and a best practice rule could be formed out of that in the validation service (validate.buildingsmart.org). cc @evandroAlfieri

[Extender-BIM]

@aothms thanks for the input, according to this list i would see "Lowercase Letter", "Uppercase Letter" and "__" as possible
separator as a possible definition. Defining Pascal Case as standard.
Still open for me is the Space in naming. In IT they invented Pascal Case to eliminate Space and keep the string readable.

[Extender-BIM]

It is definitly an important topic.
I will try to get it in our bSAT BIMcert Handbook as soon as we have clarified all 15 theses (or maybe they will be more) about Quality of Data structures.
I have already a lot of insight in different Data structures and it seems like they do what is possible as String, not being aware of the consequences.