[
Lists Home |
Date Index |
Thread Index
]
7/19/2002 6:57:28 PM, Robert Leftwich <robert@leftwich.info> 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. ]
|
