XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] RE: Keep business-process-specific data separate?

interesting conversation, though IMO there is an inverse relationship
of how effective a vocabulary is to how many stakeholders/requirements
it is trying to cater too.

Putting on my pragmatic (not cynical) glasses I would respond to these
bullet points thus;

point 1. An XML vocabulary should exist in your 'vacuum'/context
first... and satisfy your own requirements, otherwise you never get
past the first hurdle

point 2. If an XML vocabulary is too generic it will fail

point 3. there is another kind of data, that for which you do not know
what to do with or has yet to be created/imagined

point 4. An XML vocabulary should first support the needs of the data
consumers otherwise there isn't a point. This conflicts with point 1
that I make ;)

point 5. if there is markup relevant to data consumers but data
producers have nothing to do with it, leave it to consumers to suggest
how best to add/amend ... this is where namespaces and compound
documents start becoming relevant.

6. design flexibility and extensibility in your data models, but do
not try to predict the future

7. modularity whilst useful, smacks of reuse and as we all know reuse
is an ethereal creature that hardly exists ... perhaps reuse is
enshrined in the fact that we use xml itself as the basis to define a
vocabulary. Modularity also can have a performance aspect in being
able to choose only that which you use ... performance hint at
optimization  (and all the caveats that go with that apply when to do)

8. to many options will reduce comprehension and gravitas of your core
vocabulary, the sum result being probably poorer adoption
characteristics

from an audit point of view, the envelope that PaulS mentioned seems
like a pragmatic approach.

your points as rules of thumbs are good, but I think the old adage of
'plan to throw away the first system' ... though how one convinces
business & clients to pay for 2 systems is a mystery to me.

have a good weekend.

cheers, Jim Fuller


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


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

Copyright 1993-2007 XML.org. This site is hosted by OASIS