[Peter Ahlstrom]

In this case, it also works fine in the readers that I've tested. So if it's not explicitly disallowed in the spec, I'm not sure why (even if it's not explicitly mentioned as allowed) it should be considered invalid. It still seems to me like of course it's something that should be allowed.

The programmers making this test in the validator would have to 1. Check to see if any navpoints point to the same target. 2. Check if the navpoints have the same playOrder. That is the only way this specific validation test could have been programmed, that I can see. There is no way they could program that in without anticipating the possibility of a test where only #1 is the case. So, reading the spec, the programmers must have assumed (as I have assumed) that #1 by itself is not an error at all, but works as intended.

So I just looked at the source code for the IDPF validation and it has this:

    <sch:pattern name="ncx_playOrderMatch2" id="ncx_playOrderMatch2">
      <!-- navPoints, navTargets, and pageTargets that have identical playOrder values must point to same target -->
      <sch:rule context="//*[@playOrder]">
        <sch:assert test="count(//*[@playOrder][number(@playOrder)=number(current()/@playOrder)]/ncx:content[@src != current()/ncx:content/@src])=0">
          identical playOrder values for navPoint/navTarget/pageTarget that do not refer to same target
        </sch:assert>        
      </sch:rule>
    </sch:pattern>

    <sch:pattern name="ncx_playOrderMatch" id="ncx_playOrderMatch">
      <!-- navPoints, navTargets, and pageTargets that point to same target must have identical playOrder values -->
      <sch:rule context="//*[@playOrder][ncx:content]">
        <sch:assert test="count(//*[@playOrder][ncx:content][ncx:content/@src=current()/ncx:content/@src][number(@playOrder)!=number(current()/@playOrder)])=0">
          different playOrder values for navPoint/navTarget/pageTarget that refer to same target
        </sch:assert>        
      </sch:rule>
    </sch:pattern>

It has both the positive test and the negative test. It checks to see if different navpoints pointing to the same target have the same playOrder, AND it checks to make sure that items with the same playOrder point to the same target. There is absolutely no way they would implement the second type of test if they didn't think it was valid for "same playOrder" cases to exist.

Now, that's their interpretation of the spec, but if anything, this proves I'm no more crazy in my interpretation than the validatior programmers.