[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Designing XML to Support Information Evolution
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|