This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Conditional document merge


> I think the order / structure is the fundamental aspect of your output
> document, and it seems wierd that one of your documents (A) has all the
> required elements but not necessarily the order while the other (B) has
the
> order but not necessarily all the elements - if (B) doesn't have all the
> elements, how can it have the entire order? 

The odds of document B not having all the elements are low, it would usually
indicate that document B is out of date, but it's a condition I have to
allow for.  As such, the answer is, it document B doesn't necessarily have
the _entire_ order, just the order of the elements that where known at the
time it was created (or the elements that were deemed mandatory at the time
it was created).  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.  There could be
gaps of several elements: we've had cases where 6 or 7 new elements have
been added at a time, but so far such additions have never involved anything
deemed to be mandatory. 

[FYI: These documents support a research environment where new "discoveries"
are added on a continual basis.  Document A is essentially a master list
maintained by an administrator.  Document B is a particular researcher or
departments view of the list and given the nature of the research there may
be some variances on how well the views of the world match up...]

> If (as your example suggests) the order is implicit in the data then it
> would make sense to use A as the basis of the merge, sort on this implicit
> order, and use B as a kind of element-mask.

I suspect that is indeed the case, I'm having problems figuring out how the
actual sort would look when it involves two documents like this.  I keep
ending up with convoluted schemes involving variables holding one or the
other documents and having to use node-set extensions to handle things. I
could really use some pointers on how to cross references two documents in
an efficient manner...


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]