Schema documentation for component diggs:CompositeAcceptanceCriterion

A requirement formed by combining two or more separately stated acceptance criteria under one logical operator, for example the drilling refusal rule "penetration rate below X and torque above Y". Each member is a normally declared criterion with its own subject, statistic, operator, limit, basis and evaluated-against references, evaluated on its own terms; the composite combines their verdicts and has no statistic, basis or base length of its own. A member may have a different kind of subject from the composite: a requirement about the act of construction, such as a refusal rule, is judged on the construction activity cited through constructionActivityRef, while the composite is judged on the feature. A construction activity member applies to the feature named by that activity's samplingFeatureRef; where several activities act on the feature, the latest by activityDateTime counts. The composite substitutes diggs:AbstractProgramSpecification, so it is accepted wherever a diggs:PerformanceCriterion is.

<diggs:CompositeAcceptanceCriterion gml:id="" xmlns:diggs="http://diggsml.org/schemas/3" xmlns:gml="http://www.opengis.net/gml/3.2">
  <gml:description xlink:href="" nilReason="">{0,1}</gml:description>
  <gml:identifier codeSpace="">{0,1}</gml:identifier>
  <gml:name codeSpace="">{0,unbounded}</gml:name>
  <diggs:internalIdentifier codeSpace="">{0,1}</diggs:internalIdentifier>
  <diggs:status codeSpace="">{0,1}</diggs:status>
  <diggs:implementationStatus codeSpace="">{0,1}</diggs:implementationStatus>
  <diggs:associatedFile xlink:href="" nilReason="" owns="false">{0,unbounded}</diggs:associatedFile>
  <diggs:role>{0,unbounded}</diggs:role>
  <diggs:remark>{0,unbounded}</diggs:remark>
  <diggs:basedOnRef xlink:href="" identifierRef="" nilReason="" owns="false">{0,1}</diggs:basedOnRef>
  <diggs:basisRef xlink:href="" identifierRef="" nilReason="" owns="false">{0,1}</diggs:basisRef>
  <diggs:appliesToZone xlink:href="" nilReason="" owns="false">{0,1}</diggs:appliesToZone>
  <diggs:appliesToFeatureType codeSpace="">{0,1}</diggs:appliesToFeatureType>
  <diggs:logicalOperator>{1,1}</diggs:logicalOperator>
  <diggs:criterionRef xlink:href="" identifierRef="" nilReason="" owns="false">{2,unbounded}</diggs:criterionRef>
  <diggs:partOfSpecificationRef xlink:href="" identifierRef="" nilReason="" owns="false">{0,1}</diggs:partOfSpecificationRef>
</diggs:CompositeAcceptanceCriterion>

Database handle for the object. It is of XML type ID, so is constrained to be unique in the XML document within which it occurs. An external identifier for the object in the form of a URI may be constructed using standard XML and XPointer methods. This is done by concatenating the URI for the document, a fragment separator, and the value of the id attribute.

<element name="CompositeAcceptanceCriterion" type="diggs:CompositeAcceptanceCriterionType" substitutionGroup="diggs:AbstractProgramSpecification"> <annotation> <documentation>A requirement formed by combining two or more separately stated acceptance criteria under one logical operator, for example the drilling refusal rule "penetration rate below X and torque above Y". Each member is a normally declared criterion with its own subject, statistic, operator, limit, basis and evaluated-against references, evaluated on its own terms; the composite combines their verdicts and has no statistic, basis or base length of its own. A member may have a different kind of subject from the composite: a requirement about the act of construction, such as a refusal rule, is judged on the construction activity cited through constructionActivityRef, while the composite is judged on the feature. A construction activity member applies to the feature named by that activity's samplingFeatureRef; where several activities act on the feature, the latest by activityDateTime counts. The composite substitutes diggs:AbstractProgramSpecification, so it is accepted wherever a diggs:PerformanceCriterion is.</documentation> </annotation> </element>

Showing: