Quelqu'un peut-il aider à savoir si les noms de type d'entité IFC sont sensibles à la casse ou à la casse?
Par exemple: Pouvons-nous remplacer IFCPERSON par IfcPerson (cas du chameau) ou ifcperson (petit) dans un fichier * .ifc? < / p>
3 Réponses :
Que diriez-vous d'appliquer la convention suivante dans chaque contexte:
Supposons simplement qu'ils respectent la casse et fonctionnent en conséquence.
Si vous faites toujours cela, vous n'aurez jamais de problème.
Si vous voyez différents exemples de casse, et que tous fonctionnent, vous pouvez supposer que ce n'est pas sensible à la casse.
Sinon, vous serez toujours du bon côté si vous suivez simplement les conventions de cas que vous voyez et sont prouvées.
De plus, vous devez toujours implémenter des tests unitaires pour chaque élément de fonctionnalité.
Si vous avez des questions sur le respect de la casse, implémentez des tests unitaires pour prouver que vos hypothèses sont correctes.
Savez-vous ce qu'est IFC? Selon votre réponse, vous ne parlez que d'alphabets. parce que mon problème est que si le cas est sensible, ce sera le haut ou le chameau. Comme les deux formats fonctionnent pour moi pendant mes tests
Je sais ce qu'est IFC. J'étais l'un des membres fondateurs et secrétaire international mondial de l'IFC il y a deux ou trois décennies :-) Selon la spécification de format de fichier STEP, «Les instances de types de données à entité unique sont représentées en écrivant le nom de l'entité en majuscules ", cf. la [Description Wikipedia ISO 10303-21] ( en.wikipedia.org/wiki/ISO_10303-21 < / a>).
Cependant, les boîtes à outils IFC sont souvent implémentées dans un langage sensible à la casse, par exemple C ++, et utilisent la casse camel des noms d'entités pour une meilleure lisibilité. Donc je suppose que cela dépend du contexte.
Vous voudrez peut-être jeter un coup d'œil à une version en ligne d'ISO10303-p21 qui définit le format de données STEP (format de fichier des fichiers .ifc).
Le chapitre 5.4 définit le format des jetons, auxquels appartiennent les noms d'entités, pour ne contenir que des lettres majuscules et des chiffres. Donc, fondamentalement, ils sont sensibles à la casse, ce qui signifie qu'ils ne peuvent contenir que des lettres majuscules.
Je suis d'accord avec vous Monsieur, que l'ISO est sensible à la casse et que l'IFC l'utilise pendant son travail, mais ce sont des normes ISO, elles parlent de mots-clés utilisés dans Iso et son format. Mais la construction intelligente avait défini ses entités IFC, je veux juste savoir si elles sont toutes supérieures ou Camel Case.
Buildingsmart utilise le format de données STEP pour ses fichiers .ifc. Les règles d'ISO-10303-p21 s'appliquent donc à ces fichiers. Dans la spécification (par exemple, buildingsmart-tech.org/ifc/IFC4/Add2TC1/ html ainsi que la spécification de schéma EXPRESS), ils utilisent le cas camel. Néanmoins, si vous souhaitez écrire des fichiers .ifc conformes aux normes, vous devrez respecter le format de données STEP.
Je ne considérerais pas cette sensibilité à la casse. Dans ce contexte spécifique, je parlerais de la sensibilité à la casse si les identificateurs pour les types d'entités avec des cas différents dénotaient différents types. Techniquement, cela n'est pas possible si le boîtier est fixé à la partie supérieure. Les noms de type d'entité dans EXPRESS sont définitivement insensibles à la casse et la restriction en majuscules pour les fichiers STEP est juste là pour éviter toute confusion.
Voyons comment les cas sont définis dans les normes pour EXPRESS (utilisé pour spécifier le schéma) et pour les fichiers physiques STEP (utilisés pour les fichiers * .ifc réels).
Selon ISO10303-11 , en EXPRESS, les noms d'entités sont des cas -insensible. La grammaire ne mentionne que les lettres minuscules pour les identifiants d'entité (section 7.4 Identifiants et 7.1.2 Lettres), en réservant les majuscules aux mots réservés EXPRESS tels que ENTITY . P >
#1 = IFCPERSON('ID', 'Last', 'First', $, $, $, $, $));
Un schéma ne peut donc pas définir deux types d'entités différents qui ne diffèrent que par leur casse. De plus, la norme indique explicitement l'insensibilité à la casse:
EXPRESS utilise les lettres majuscules et minuscules de l'alphabet anglais [..] La casse des lettres n'est significative que dans les chaînes littérales explicites. REMARQUE - EXPRESS peut être écrit en majuscules, minuscules ou en majuscules [..].
Ainsi, le cas de chameau que vous voyez dans les définitions IFC-EXPRESS (par exemple pour IFC4 ) et dans le BuildingSMART correspondant documentation n'est pas significatif et juste choisi pour des raisons de lisibilité.
En ce qui concerne le Encodage de fichier physique STEP ( ISO10303-21 ) et vos fichiers d'instance réels, la grammaire mentionne uniquement les caractères majuscules pour les types d'entités:
ENTITY IfcPerson;
ISO10303-21 spécifie en outre comment mapper la définition de schéma au fichier IFC réel (section 12.2.). En ce qui concerne le codage des noms de type d'entité, il indique que les fichiers STEP ne doivent utiliser que des majuscules.
[..] Dans les deux cas, les minuscules doivent être converties en leur lettres majuscules correspondantes, c'est-à-dire que le codage ne doit pas contenir toutes les petites lettres.
Cela garantit également l'insensibilité à la casse, mais d'une manière différente que dans EXPRESS.
Pour revenir à la question initiale, si IFCPERSON peut être remplacé par IfcPerson . Si vous où écrire le standard, vous pouvez utiliser n'importe quelle casse, car les noms de type d'entité sont insensibles à la casse.
SIMPLE_ENTITY_INSTANCE = ENTITY_INSTANCE_NAME "=" SIMPLE_RECORD ";" .
SIMPLE_RECORD = KEYWORD "(" [ PARAMETER_LIST ] ")" .
KEYWORD = USER_DEFINED_KEYWORD | STANDARD_KEYWORD .
STANDARD_KEYWORD = UPPER { UPPER | DIGIT } .
UPPER = "A" | "B" | "C" | .. | "X" | "Y" | "Z" | "_" .
Si vous écrivez un fichier IFC-STEP, un Une interprétation stricte de la norme nécessiterait d'écrire les noms des types d'entités en majuscules.
entity_head = ENTITY entity_id subsuper ";" .
entity_id = simple_id .
simple_id = letter { letter | digit | '_' }
letter = 'a' | 'b' | 'c' | ... | 'x' | 'y' | 'z'
En pratique, les analyseurs doivent de toute façon se fier à l'insensibilité à la casse du schéma. Ainsi, ils effectueront une comparaison insensible à la casse avec les noms de types d'entités définis par le schéma. Ils accepteront très probablement des noms de type d'entité mixtes ou minuscules dans le fichier * .ifc.
Mais un analyseur pourrait également rejeter un fichier IFC avec des noms de type d'entité à casse mixte comme non conforme à la norme ou ignorez simplement les entités qui ne sont pas entièrement en capital. Imaginez une implémentation qui convertit simplement les définitions de schéma en majuscules, puis effectue une recherche sensible à la casse pour les types d'instances d'entité. Ce serait parfaitement conforme à la norme.