Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML strategies
 7/19/2002 6:57:28 PM, Robert Leftwich <robert@l...> wrote: >In the absence of a >particular ML for the domain I wonder how best to position the company to >take advantage of more specific ML's if and when they become available. For >example, is it best to pick an underlying component-oriented ML, such as the >foundations of xCBL or OAGIS or is it better to pick and choose relevant ML >from OASIS, OAGIS, etc as required with no regard to common base >representations or should I just build everything from scratch and migrate >when the requisite ML appear at some future date? My sense of best practice is: - Start from your own requirements and business processes and adopt, wholesale or piecemeal, those existing schemas and technologies that fit them. On the other hand, schema design is not a job for novices, so understand and use at least the "design patterns" of schemas that have had a lot of thought and expertise put into them. - Starting with someone else's schema or business process and trying to adapt it to your needs is expensive; adapting your business processes to the "standard" is generally disastrous (standards being least common denominators at best, and metamodel frameworks without out-of-the-box interoperability at worst). [Larry Ellison, of course, speaks out against this point of view regularly, so someone from Oracle might want to set me straight here :~) ] Of course, if you are small enough and generic enough, the common denominator / off the shelf solution may be good enough! - In general, many small schemas work better than trying to find the One True Schema. - Assume that the "requisite ML" will never appear. If your industry / agency / whatever could agree on a common data format, they probably would have long ago, and coming up with an XML version would have been accomplished by now. Collective schema development is all about pragmatism, politics, power, and personality, not technology. - "XML enable" your existing processes, don't reinvent them for XML ... or reinvent them piecemeal as your experience/comfort level grows. Learn to translate from your OWN standard format to whatever industry exchange standards eventually emerge. - Don't sniff too much XML pixie dust :~) XML is good for some things, and lousy at others (referential integrity comes to mind). Dont't agonize over how to use XSLT or XML schemas of one sort or another to process and validate your data if you can call some existing or easily-written code to make the checks and transformations that you REALLY want to make. [disclaimer -- my humble opinions, not the corporate line .... and I've gotten this more from hanging around with real developers and listening to their war stories than from actual service in the trenches. ] 
|
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
|
|||||||||
