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] The Rise of Worse is Better

There'd been some discussion about ACCORD during this process, and a lot of the ACCORD model actually informs the NIEM model that's being rolled out. I believe the decision to go to NIEM came in part because DHS is a pretty major player in this as is HHS, and both had NIEM models in other domains, so there was a question ultimately as to whether it made more sense to adopt an industry standard or establish a federal one. This would end up being a full NIEM domain in that respect, and given that it looks like the Federal government is now in the health insurance business in a big way, I think the decision was made to effectively own the standard.


Kurt Cagle
Invited Expert, XForms Working Group, W3C
Managing Editor, XMLToday.org
kurt.cagle@gmail.com
443-837-8725




On Wed, Aug 29, 2012 at 2:25 PM, Fraser Goffin <goffinf@gmail.com> wrote:
Kiurt,

I can empathyse, but what's up with ACCORD or Origo or Polaris. Aren't
these insurance industry standards that could provide you with a head
start both on semantics as well as syntax, and tolling and run-times ?

And if you need some more generalised information items, UBL, et al

Fraser

On 29/08/2012, Kurt Cagle <kurt.cagle@gmail.com> wrote:
> Roger,
>
> First - I wanted to say again how much a pleasure it was to finally meet
> you at Balisage. I only regret that I was not able to stay for the full
> conference.
>
> There is an old cantrip to the effect that Perfection is the Enemy of the
> Good. It is used to justify a great number of sins in programming as
> elsewhere, and I'd argue that while there is benefit to this position,
> there's also a point where Mediocrity is just as much the enemy of the
> Good, and in many respects far more dangerous.
>
> I can give a good example of this from my own work. I am working on, among
> other things, trying to develop an ontology for data interchange in a
> Federal insurance program.  It is a project that suffers from vendoritis -
> the project is time constrained, and the vendors and primary contractors on
> the project, eager to start billing hours, started programming long before
> requirements were fleshed out, before data models were even understood, and
> before larger stage planning had fully been accomplished. This meant that a
> lot of schemas were surfaced that consisted primarily of attributes taken
> out of a relational database table or a screen-scraped form and thrown into
> a flat XML structure. Given that there were dozens of participants in this
> particular process, each of which had a need to talk to one another (but
> that weren't doing it just yet), what eventually emerged were dozens of
> different approaches to handle the same process. As a consequence, much of
> the code that has been written to date built around a web services
> framework now suffers from Babel syndrome, and XSLT transformations are put
> into overtime work to try to keep communication going just between two
> parties. Because of performance issues, fully 2/3 of this code will likely
> have to be thrown out.
>
> I've been pushing to get a NIEM based standard in place, but it's been a
> real uphill slog, not least of which because NIEM itself is a complex
> schema that Java developers especially tend to dislike because they have to
> cross namespaces, which adds complexity to their JAXB code. So why NIEM?
> Partially because it does a reasonably good job (once you understand what
> you're doing) in modeling a lot of the core objects that this kind of
> application tends to have, it establishes a formal discipline on naming
> conditions and rules that multiple distributed partners can work with, and
> it has a known development and distribution process. It's also something
> that other Federal agencies are moving towards for the kind of people
> management exercise found in this project.
>
> So in many respects the worse is not better than "good". The more integral
> a piece of software is to a system, the more that flawed code, poor design
> and interface decisions, and a lack of consideration for broader
> architecture will impact upon the ecosystem that evolves around that
> product. In an ecosystem starved for alternatives, the "poor" might
> actually gain some traction because the alternative is the "none" but any
> more, the ecosystem is generally far from starved. There is a case for not
> trying to go to perfection, of course - business requirements change, which
> in turn force changes into technical specifications, so perfectly tailored
> solutions will eventually get out of sync, but I think its a case where
> what you should be striving for is flexibility and balance - sacrificing
> more development time and perhaps some performance in order to make a
> component sufficiently flexible to meet the business needs for a longer
> period of time, and hence allow for a some redundancy in the system.
>
> Kurt Cagle
> Invited Expert, XForms Working Group, W3C
> Managing Editor, XMLToday.org
> kurt.cagle@gmail.com
> 443-837-8725
>
>
>
>
> On Wed, Aug 29, 2012 at 7:13 AM, Costello, Roger L.
> <costello@mitre.org>wrote:
>
>> Folks, Hello,
>>
>> I just read an interesting article titled, The Rise of Worse is Better.
>>
>>     The lesson to be learned from this is that it is often undesirable
>>     to go for the right thing first. It is better to get half of the
>> right
>>     thing available so that it spreads like a virus. Once people are
>>     hooked on it, take the time to improve it to 90% of the right thing.
>>
>> I think this lesson applies to XML as well. Rather than developing a data
>> model (e.g., XML Schema) that tries to do everything, create a simple
>> data
>> model that spreads like a virus and then take the time to improve it.
>>
>> More ... http://www.dreamsongs.com/RiseOfWorseIsBetter.html
>>
>> Thoughts?
>>
>> /Roger
>>
>> _______________________________________________________________________
>>
>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>> to support XML implementation and development. To minimize
>> spam in the archives, you must subscribe before posting.
>>
>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>> subscribe: xml-dev-subscribe@lists.xml.org
>> List archive: http://lists.xml.org/archives/xml-dev/
>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>>
>>
>

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php




[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