RE: Conditional document merge

> If things subsequently change the order of any missing
> elements has to be based on some default; in this case, after the closest
> element that was known at the time document B was created. 
>
>I didn't understand this, you said doc a was essentially unordered,
>I can understand going through doc b and producing the output, you
>describe but the only way I understand to get all the @required elements
>from doc a that are not in b is to put them all at the end.

Sorry, from the users point of view Document A is unordered, but from an
overall system point of view, the order in document A is as good as anything
else (it actually does have an explicitly defined order, however, the users
may choose to disagree with it).

> If you go the document B you don't know until the end that any required 
> elements are not listed do you?
>
> But you have a notion of closest above and in your original you said
> any missing nodes can be substituted immediately following
> any previous match. neither of which I understand:-)

I believe I can pick up on the missing elements as soon as I've passed them
by. If I have two sorted trees to compare and in one I go from A to C and in
the other I go from A to B then I know I've missed B in the first?  However,
that where I get stuck; it seems like a lot of messy XPath...

> In your example required output <d> got out out because it was required,
but why
> did it come at the end (unless all such come at the end)

It got output at that point because it followed element C.  The example
should have gone on longer to make this clearer...  An additional condition
would be that if you get to the end and you still haven't output a required
element then it would have to output at that point, but that shouldn't be
the case for all required elements.

I really don't want to have to output all missing required elements at the
end of the output.  Worse case they could come after the last required.
However, if a new required element is added after the fact then it's likely
it has come contextual relationship to it's neighbors and the researchers
really need to be able to see this.  

FYI, we have been playing around with just throwing some kind of error if
document B doesn't contain all the mandatory elements.  Forcing the user
level administrators to go back and rebuild document B wouldn't be very
popular, but it should be a rare event (once every couple of months
perhaps).  The test for throwing the error would be to find the intersection
of all the mandatory elements in document B with all the elements defined in
document A.  It seems a similar test would tell me if any given element was
missing?


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list