-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple <attDef>
s with the same @ident
in the same <attList>
should be invalid
#2371
Comments
I am not sure I agree with this, though it's an obvious optimisation that any implementer might choose to make, and I have no quarrel with your doing so in ATOP. But for the record, the reason it's like that is that I at least thought you might well want to take several bites at the definition of an attribute in an ODD chaining context. For example, you might define a base set of @type values in your "mother" ODD, and then add different sets of extra values in ODDs which are chained to it (or do I mean from it). Yes, of course you risk shooting yourself in the foot by making contradictory assertions for the same attribute, but that happens elsewhere too. If you're clever enough to chain your ODDs you're probably clever enough to notice such errors. |
@lb42 — |
I should add that I am not 100% convinced @martindholmes is right (that having 2 occurrences of that same XPath within the same That is because the only reason I can come up with on-the-spot for allowing this would be so that users could group all of their But I think it worth asking if there are other use cases that I have not thought of that might make this an important capability to retain in PureODD. |
What I'm actually suggesting is much more constrained than the discussion @sydb has opened up. I think it should be invalid to have multiple On the question of whether a similar constraint should be applied to (e.g.) multiple |
So, @martindholmes, you are suggesting we not allow 2 (or more) Since So, thinking a bit about <elementSpec ident="BG" mode="add" ns="http://www.example.edu/medical/chart/ns">
<gloss>blood glucose</gloss>
<classes>
<memberOf key="att.global"/>
<memberOf key="att.datable.w3c"/>
<memberOf key="model.XMCdata"/>
</classes>
<content><empty/></content>
<!--
Here is the interesting bit — two mutually exclusive definitions
of the same attribute:
-->
<attList org="choice">
<attDef ident="value">
<desc>30–499 mg/dL</desc>
<datatype minOccurs="1" maxOccurs="1">
<dataRef name="positiveInteger" restriction="([3-9]|[1-4][0-9])[0-9]"/>
</datatype>
<remarks>
<p>A decimal point is not permitted.</p>
</remarks>
</attDef>
<attDef ident="value">
<desc>1.6–27.6 mmol/L</desc>
<datatype minOccurs="1" maxOccurs="1">
<dataRef name="decimal" restriction="(1\.[6-9])|(([2-9]|1[0-9]|2[0-6])\.[0-9])|(27\.[0-6])"/>
</datatype>
<remarks>
<p>The decimal point is required.</p>
</remarks>
</attDef>
</attList>
</elementSpec> Sure, there may be better ways to do that, but I am not sure someone who has crafted this wants to be yelled at about having two Notes <sch:rule context="tei:attDef[@ident]">
<sch:let name="ident" value="normalize-space(@ident)"/>
<sch:report test="following-sibling::tei:attDef[ normalize-space(@ident) eq $ident ]">
Only one definition of a given attribute allowed per attribute list.
(In this case "<sch:value-of select="$ident"/>" is defined <sch:value-of select="count(../tei:attDef[ normalize-space(@ident) eq $ident ] )"/> times.)
</sch:report>
</sch:rule> [3] Here is a better crack at it. This one correctly handles nested attribute lists, except that it simply ignores any attribute defined inside a choice attribute list. <sch:rule context="tei:attList[ not( ancestor::tei:attList ) ]">
<!-- generate a sequence of my <attDef> descendants (that are not alternates): -->
<sch:let name="defs" value="descendant::tei:attDef[ not( parent::tei:attList[ @org eq 'choice'] ) ]"/>
<!-- get a sequence of the @idents of those <attDef>s: -->
<sch:let name="idents" value="$defs/normalize-space(@ident)"/>
<!-- get a sequence of any that occur 2+ times: -->
<sch:let name="dups" value="for $n in $idents return $idents[ . eq $n ][2]"/>
<!-- remove any duplicates in the list of duplicates (-: -->
<sch:let name="distinct_dups" value="distinct-values( $dups )"/>
<!-- if there any values in list of distinct duplicates, warn user about them: -->
<sch:assert test="count($distinct_dups) eq 0">
Within this attribute list the following attributes have been defined multiple times: <sch:value-of select="$distinct_dups"/>.
</sch:assert>
</sch:rule> [4] Both [2] and even [3] are a bit too permissive. That is, they will incorrectly fail to flag some unusual cases as errors; but I do not think either would falsely flag anything that is OK as an error. |
@sydb I don't understand how a schema processor or validator could distinguish between two definitions of the same attribute, especially when their definitions are incompatible. How would that work in practice? What's the use-case? |
Sorry, @martindholmes, perhaps because it is way past my bedtime, I don’t get the question. Are you asking about having two definitions of an attribute with the same name in alternation with one another (in which case I think the use case given above is pretty compelling, no?) or defining two attributes with the same name that could be on the same element at the same time (which is simply not allowed, so not of any concern to us here)? |
Just making a note that in order to create this problem, you need to create attDefs with different idents but with the same altIdent. Although the |
Council F2F Paderborn: We recognize potential issues with ODD chaining in processing a choice between two definitions of an |
Update: @sydb has tested and found the use of |
So given Council’s approval of the restriction “within an <sch:pattern>
<sch:rule context="tei:attList[ not( ancestor::tei:attList ) ]">
<!-- generate a sequence of my <attDef> descendants -->
<sch:let name="defs" value="descendant::tei:attDef"/>
<!-- get a sequence of the @idents of those <attDef>s: -->
<sch:let name="idents" value="$defs/normalize-space(@ident)"/>
<!-- get a sequence of any that occur 2+ times: -->
<sch:let name="dups" value="for $n in $idents return $idents[ . eq $n ][2]"/>
<!-- remove any duplicates in the list of duplicates (-: -->
<sch:let name="distinct_dups" value="distinct-values( $dups )"/>
<!-- if there are any values in list of distinct duplicates, warn user about them: -->
<sch:assert test="count($distinct_dups) eq 0">
Within this attribute list the following attributes have been defined multiple times: <sch:value-of select="$distinct_dups"/>.
</sch:assert>
</sch:rule> Except that it does not take into account |
The ATOP group (@sydb, @martindholmes, & @HelenaSabel) discussed this in detail. We think that:
Thus making GREEN for adding this rule. In discussing this we came across another combination that makes no sense; see #2533. |
Just so we’re all on the same page, I claim the following should be invalid. <attList>
<attDef ident="a"/>
<attDef ident="b"/>
<attList org="choice">
<attDef ident="b"/>
<attDef ident="c"/>
</attList>
<attDef ident="d"/>
</attList> Even though it is possible to write an XML document that conforms to this (by picking choice I am going to proceed on this ticket under the assumption that everyone agrees with this position. So if you disagree, speak up! |
Another post along the same lines — Is it OK to have two or more |
that flags as an error any 2+ attDef elements who both share an ancestor attList and have the same ident= attribute (regardless of the mode= attr value) unless they are both (all) children of an attList that has an org= attribute value of "choice".
that flags as an error any 2+ attDef elements who both share an ancestor attList and have the same ident= attribute (regardless of the mode= attr value) unless they are both (all) children of an attList that has an org= attribute value of "choice".
that flags as an error any 2+ attDef elements who both share an ancestor attList and have the same ident= attribute (regardless of the mode= attr value) unless they are both (all) children of an attList that has an org= attribute value of "choice".
In the ATOP work, we came across an in-vivo ODD file which has this content:
The repetition of the
@type
attDef is clearly an error, but it's not invalid against tei_odds or tei_all. I propose introducing a Schematron rule to prevent this. In cases where multiple definitions are not identical, then a significant burden would be placed on a) maintainers of the ODD specification to specify exactly how they bear on each other and how they are expected to be combined during processing, and b) maintainers of processing tools. Forcing ODD writers to consolidate their modifications to a single attribute into a single<attDef>
seems far preferable. A simple Schematron rule would constrain this.The text was updated successfully, but these errors were encountered: