[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: csprd03 - Constraints in 5.5.4.3 resourceItemRef and 5.5.4.4 resourceItem
After a closer look, I think it is more likely that we would need to keep <res:resourceItem> id attributes unique. I’m not so sure the case for <res:resourceItemRef> is as strong.
But it still holds true that with only zero or one <res:resourceData> now allowed in <file> or <unit> we no longer need to keep them unique among their containing <file> or <unit> elements. So I now propose just option 2: Edit the constraint to say ” The value of the OPTIONAL id attribute MUST be unique among all <resourceItem> and <resourceItemRef> elements of the enclosing <res:resourceData> element.” From: Schnabel, Bryan S [mailto:bryan.s.schnabel@tektronix.com]
The constraints in 5.5.4.3 resourceItemRef and 5.5.4.4 resourceItem say “The value of the OPTIONAL id attribute MUST be unique among all <resourceItem> and <resourceItemRef> elements of the immediate enclosing <file> or <unit> element.”
Since we agreed to make <res:resourceData> Zero or One for <file> and <unit>, there will never be a case where sibling <res:resourceData> elements have potentially conflicting @id values for <res:resourceItemRef> or <res:resourceItem>. So the only conflict
that could be impacted (and this seems like a nearly non-existent use case) is if for some reason FragID needed to discern between them. Seems like a lot of baggage to support such a corner case. I suggest we either (1) remove the constraint all together,
or (2) edit the constraint to say ” The value of the OPTIONAL id attribute MUST be unique among all <resourceItem> and <resourceItemRef> elements of the enclosing
<res:resourceData> element.” |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]