[
Lists Home |
Date Index |
Thread Index
]
Message> What conference, might I inquire?
MISMO (Mortgage Industry Standards Maintenance Organization). As an aside,
you would be pleased, and maybe shocked, at how often the Best Practices for
XML Schemas have been cited the past two days alone. People arguing
vehemently for the Chameleon Approach, or the Venetian Blind approach, or
the Salami Slice approah. I was almost getting lost in it all :-) I won't
be surprised if I come back to this list soon with some directional
questions-- we have some tough decisions to make here (where in each case
there seems to be a signifcant tradeoff in usability). We are finding that
the decisions generally boil down to reuse versus simplicity, and giving
local processes (i.e., specific transactional areas of the Mortgage
Industrry) control versus global architectural control. So maybe there are
some interesting parallels to the work you are doing now (local picker
control versus vineyard owner control). Many of the decisions we have faced
are less technical and more business oriented. All the same, I wanted to pat
you on the back for building up those documents-- they have given us an
invaluable set of base definitions.
>>Actually, each Picker makes it decisions locally, by looking at
neighboring lots. There is no top-down code telling each Picker how to
move. It is a bottom-up approach to the Vineyard system. This is for an
"XML and Complex System's" tutorial that I am putting together. <<
I look forward to it...
>> The two lots are written to the XSLT result tree. However, Picker 2 is
doing the same thing. Thus, in the result tree we now have two different
versions of the inner lot. The only way that I could see how to do it was
to first process Picker 1, then process Picker 2 using the state that
resulted after processing Picker 1, i.e., process the lots/Pickers
sequentially. I hope that I made some sense in this description. <<
This is actually very clear now. It still strikes me as more of an XSLT
limitation than a limitation in your original data structure... though this
may be what you mean by flexibility-- the ability to use any XML tools.
Clearly flattening simplifies the processing not only from a human point of
view but probably from a computer point of view as well. Again, as a DOM
application (especially where something like selectNode or selectSingleNode
were available) it would be much simpler and could still be concurrent
(mainly because the resulting model could be concurrently modified). I think
this definitely affects the decision to flatten or not flatten, whether or
not the tools allow random access before output or only allow streaming
output.
>>An interesting idea! I shall think about this. <<
I look forward to this as well.
All the best,
Jeff Rafter
|
