Opened 6 years ago

Closed 6 years ago

#30 closed enhancement (wontfix)

allow arbitrary order of data columns in Idata group

Reported by: prjemian Owned by: prjemian
Priority: minor Version:
Keywords: Cc:

Description

Makes sense to report Q Qdev I Idev but the current rules require Q I Idev Qdev. Can this be allowed?

More to the point, must the order of data columns be exactly as described?

Change History (2)

comment:1 Changed 6 years ago by prjemian

One of the rules for Idata is picky but hard to change, that Qdev must appear *after* Idev in each Idata group. *If* that that order can be allowed to be arbitrary, we'll change the rule, otherwise it is important to note that order-of-appearance is very important. It is possible the desired flexibility may require a change from XSD Schema rules to Schematron rules and that's a major change.

comment:2 Changed 6 years ago by prjemian

  • Priority changed from major to minor
  • Resolution set to wontfix
  • Status changed from new to closed

Here's the answer about placing Qdev in an arbitrary position within the Idata group. It can't be done within XSD Schema without changing our rules a bit. The troublemaker comes when implementing the choice between using either Qdev or dQw & dQl (only Qdev -or- both dQw AND dQl). An additional bit of trouble comes from the <xsd:any> element (allows any arbitrary data column to be added).

	<complexType name="IdataType">
		<sequence>
			<element name="Q" minOccurs="1" maxOccurs="1"    type="tns:floatUnitType" />
			<element name="I" minOccurs="1" maxOccurs="1"    type="tns:floatUnitType" />
			<element name="Idev" minOccurs="0" maxOccurs="1" type="tns:floatUnitType" default="0" />
			<xsd:choice>
				<!-- [ [Qdev] | [[dQw] | [dQl]] ] -->
				<element name="Qdev" minOccurs="0" maxOccurs="1" type="tns:floatUnitType" default="0" />
				<xsd:sequence>
					<element name="dQw" minOccurs="0" maxOccurs="1" type="tns:floatUnitType" default="0" />
					<element name="dQl" minOccurs="0" maxOccurs="1" type="tns:floatUnitType" default="0" />
				</xsd:sequence>
			</xsd:choice>
			<element name="Qmean" minOccurs="0" maxOccurs="1" type="tns:floatUnitType" default="0" />
			<element name="Shadowfactor" minOccurs="0" maxOccurs="1" type="float" default="1.0" />
			<xsd:any minOccurs="0" maxOccurs="unbounded" processContents="skip" namespace="##other" />
		</sequence>
	</complexType>	

Arbitrary order of elements is provided by replacing <xs:sequence> with the <xs:all> element. But the <xs:all> does not permit a <xs:choice> or a <xs:any>. That's why we have the current rules. <xs:all> can only contain annotations or elements. No <xs:choice> or <xs:any>.

http://www.w3schools.com/schema/el_all.asp

We could handle the Qdev vs. dQw & dQl situation by allowing all three and advising that use of all of them is not expected and could be unreliable. But, the valuable <xs:any> still blocks our goal since it can't be used in <xs:all>.

To get all these, we'd have to shift to a different rule language, such as Schematron. NeXus? made this shift for just such reasons of flexibility. I suggest that we do not do that for the 1D standard, but consider it for the new multi-D standard.

Note: See TracTickets for help on using tickets.