[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Designing XML to Support Information Evolution


xslt limitation
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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.