dita — archive

General Implications of Multiple Uses of Same Topic With DifferentKeys

From: Eliot Kimber <[email protected]>
To: [email protected]
Date: Thu, 17 Feb 2011 12:36:00 -0000

Based on Chris' assertion that one can read the spec in a way that allows conforming processors to not treat this case as I've asserted they must, I've added a note to my book to the effect that because the 1.2 spec doesn't explicitly disallow this behavior it is allowed but because it doesn't also explicit mandate it, conforming processors may choose to behave a different way, so don't assume any given processor will behave this way. Having said that, I fully intend to ensure that the Open Toolkit, in particular, does behave this way, even if it means I have to rewrite the conref push processing myself. Currently that processing has a bug that causes it to fail in all cases so I can't test this particular case. That is, I intend to lobby hard that this behavior should be mandated because I think it's an exceptionally powerful feature, intended or not. Cheers, E. On 2/15/11 7:56 AM, "Eliot Kimber" <[email protected]> wrote: > Just to be clear: I'm saying that multiple renderings for conref push to > different keys bound to the same topic is required *because there's no other > way it could possibly work*, not because the spec as written explicitly > requires it. That is, the requirement is an emergent requirement stemming > from the interaction of conref push and keyref. > > But that's my question: is my analysis correct and if not, why not and what > are the possible alternative behaviors? > > Cheers, > > E. > > On 2/15/11 7:27 AM, "Nitchie, Chris" <[email protected]> wrote: > >> I agree that it's desirable, I'm reasonably sure it's allowed, but I'm >> also reasonably sure it's not mandated. If we want to say that this >> behavior is allowed/required, then I think we need to tweak the language >> in the spec, either in 1.3 or in an addendum to 1.2. And if >> use-context-dependent behavior is something that people seem to need - >> and I think it is - then I don't think this is an ideal way to support >> it, and we need to come up with easier to implement (heck, easier to >> describe) mechanisms in future versions of the spec. That's all I'm >> saying. >> >> Chris >> >>