Optionality of restriction base

[CBenghi]

As noted by @pasi-paasiala,
we need to agree whether base type restrictions are required to pass the audit.

Is the following restriction acceptable?

<ids:entity>
	<ids:name>
		<xs:restriction>
			<xs:enumeration value="IFCSTAIR"/>
			<xs:enumeration value="IFCSTAIRFLIGHT"/>
		</xs:restriction>
	</ids:name>
</ids:entity>

If not, a test case needs to be created and the audit tool should be updated accordingly.

Also consider the issue at #114

[MarcelStepien]

In my opinion the base-restriction is obsolete, since it is indirectly inferred by the datatype/measure in a property-facet (IFCTEXT checks for xs:string, IFCREAL checks for xs:double). In all other facets, such as in your example of checking entity-name, setting the base restriction to anything other then xs:string makes no sense.

One could argue that alphanumerical nomenclature can be excluded by simply restricting the base to something like xs:integer. However, this requirement can and should be solved using RegEx pattern instead.

[aothms]

I agree, this XSD base thing only increases confusion, because of the additional indirection in the mapping between IFC and XSD types. And what to do in the corner cases: e.g ifcdatetime is a str in ISO 8601 format is it XSD string or XSD date? Disclaimer: I haven't been too involved in recent discussions, I could be confusing things.

[pasi-paasiala]

I agree that there shouldn't be two ways to do the same thing. Here the question was about IFC entity. Should we add a new data type IfcClass (or something)? Also we could make the data type non-optional.

[mysterieux30]

That is true, this base attribute is bringing me into a real confusion like in this example:

         <ids:name>
            <ids:simpleValue>TreadLength</ids:simpleValue>
          </ids:name>
          <ids:value>
            <xs:restriction base="xs:string">
              <xs:pattern value="^(0*(\.\d+)|[1-9]\d*(\.\d+)?)$" />
            </xs:restriction>
          </ids:value>

In this case, for example, the value must have a predefined type that is based on simple type "string":
like:
IfcIdentifier: Defined type of simple type STRING for identification purposes.
IfcLabel: Defined type of simple type STRING for naming purposes.
IfcText: Defined type of simple type STRING for descriptive purposes.
IfcDateTime: Defined type of simple type STRING to represent a date and time.
IfcDate: Defined type of simple type STRING to represent a date.
IfcTime: Defined type of simple type STRING to represent a time.
IfcDuration: Defined type of simple type STRING to represent a duration.

In case the value has a predefined type that is based on simple type other than "string", the validation should return an error?
example:
IfcInteger: Defined type of simple type INTEGER.
IfcReal: Defined type of simple type REAL.
IfcBoolean: Defined type of simple type BOOLEAN.
IfcLogical: Defined type of simple type LOGICAL.
IfcTimeStamp: Defined type of simple type INTEGER.

[mysterieux30]

In case the restriction is added to an attribute facet / value, the type of the values is already defined in the Ifc schema, the use of base may sometimes bring the user into getting always an error when for example the predefined type is "IfcLabel" and the base has a value like "xs:integer".
Sorry for the disturbance, I'm just trying to share my thoughts with you.

[Moult]

@mysterieux30 the restriction base has no impact on the IFC data type. For attributes the IFC data type is fixed. For properties, the data type is specified using the datatype attribute. The restriction base of string in your example simply refers to the pattern value being string matching.

[CBenghi]

While the consensus seems to go in the direction of removing the base attribute from the restriction, we might need to address the fact that it's marked as required in the XSD schema definition, as @giuseppeverduciALMA, notes on buildingSMART/IDS-Audit-tool#15

<xs:complexType name="restrictionType">
  <xs:complexContent>
    <xs:extension base="xs:annotated">
      <xs:sequence>
        <xs:choice minOccurs="0">
          <xs:group ref="xs:typeDefParticle"/>
          <xs:group ref="xs:simpleRestrictionModel"/>
        </xs:choice>
        <xs:group ref="xs:attrDecls"/>
      </xs:sequence>
      <xs:attribute name="base" type="xs:QName" use="required"/>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

[mysterieux30]

CBenghi When i checked the XSD Schema using the software Altova, the base attribute was marked as optional

[CBenghi]

@mysterieux30 you are right, but we checked the XML schema, and we think this is a problem with ALTOVA.

[CBenghi]

The base attribute on restriction must be specified to comply with XML schema.
I've added checking to the audit tool (upcoming release).