Stylesheets icon indicating copy to clipboard operation
Stylesheets copied to clipboard

replacing a duplicated attribute duplicates new one

Open sydb opened this issue 6 years ago • 1 comments

I was creating a new element and wanted it to have @target, @evaluate, @targetLang (which make up att.pointing), and @match (which, with @target, makes up att.scoping). (See the related issue on those classes.)

I figured right away that if I just used

  <memberOf key="att.scoping"/>
  <memberOf key="att.pointing"/>

I would end up with an invalid schema due to duplicate declarations of @target. So I thought I would try doing the above, and then replacing @target with a local definition. I was not confident it would work, but I have to admit I expected it to either work or to fail by replacing only one of the two inherited definitions. I did not expect what happened, which was that the local definition replaced both of the inherited definitions — I still have a duplicate attribute, and it’s an exact clone. Sigh.

Here is a teeny tiny ODD that demonstrates the problem. Note that GitHub would not let me upload a .odd file, so I appended ".txt" to the name. demo.odd.txt

I suspect, but certainly do not know, that this happens because the code in odd2odd.xsl that does replacement searches for any (and all) declarations in the source ODD that match the name of the thing replacing it (them), and then processes the replacement once for each it found.

Note: for reasons I can’t explain and may well merit another ticket, using just <attRef> does not work. When I try

	  <attList>
	    <attRef class="att.scoping" name="target"/>
	    <attRef class="att.pointing" name="targetLang"/>
	    <attRef class="att.pointing" name="evaluate"/>
	    <attRef class="att.scoping"  name="match"/>
          </attList>

only the attributes from att.pointing are included in the schema; those from att.scoping are not.

UPDATE: I can explain, in part. The above works iff the certainty module is included, but not otherwise. (Fails even when the att.scoping class is explicitly included with <classRef>, so this is still a problem that deserves another ticket, but I have to go catch a train.)

sydb avatar Apr 30 '19 19:04 sydb

Have you tried redefining the class so that one of them does not provide @ target?

<classRef key="att.pointing" except="target"/>

lb42 avatar Aug 08 '19 14:08 lb42