OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XML strategies

[ 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.  ]

  • References:


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS