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:]

Sent: Monday, February 24, 2014 4:49 PM

To: 

Subject: [xliff-comment] csprd03 - Constraints in 5.5.4.3 resourceItemRef and 5.5.4.4 resourceItem

 

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.”