[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Partyin' like it's 1999

• To: Bill de hÓra <bill.dehora@p...>, <xml-dev@l...>
• Subject: RE: Partyin' like it's 1999
• From: "Chiusano Joseph" <chiusano_joseph@b...>
• Date: Thu, 28 Oct 2004 09:59:37 -0400
• Thread-index: AcS813kkotylFiy/SSqvpxA1WQfLbAAHsrAg
• Thread-topic: Partyin' like it's 1999

> -----Original Message-----
> From: Bill de hÓra [mailto:bill.dehora@p...] 
> Sent: Thursday, October 28, 2004 6:14 AM
> To: xml-dev@l...
> Subject: Re:  Partyin' like it's 1999
> 
> Ronald Bourret wrote:
> > Yes. I've seen it in at least one other organization as 
> well. My point 
> > is that it hasn't crossed schema boundaries and become universal in 
> > the way people thought it might. (There might very well be a good 
> > reason for this. For example, given the potential complexity of 
> > addresses, somebody designing for a local market might be making a 
> > very good design decision to ignore all that complexity and simply 
> > encode the address schema that fits their locale.)
> 
> I see two issues to consider beyond the usual interop 
> concerns; dependency management 

Dependency management - a perfect job for an XML Registry (wearing OASIS/ebXML Registry TC member hat).

Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Strategy and Technology Consultants to the World

> and engineering cost.
> 
> Mapping XML content models can represent significant work, yet it's
>   often desirable to reduce outside dependencies. Many groups don't
>   reuse schemata because they're wary of being broken by 
> another spec outside their control. For example, the Atom 
> effort has a large percentage of elements that could be taken 
> from other specs such as dublin core - the consensus 
> nonetheless has been to retain control of the spec through 
> re-invention.
> 
> Normally the focus is solely on interop, but it's a mistake 
> to ignore the costs of supporting generic formats. When you 
> do decide to reuse, some uber-content standards* can be so 
> generic and are trying to cover off so much ground you risk 
> overspend and system robustness in simply being conformant. 
> Which is to say the interop/implementation costs can be high 
> enough to constitute overengineering and can put systems and 
> projects at risk. The agile folks call this design 
> speculation  "speculative generality". The ideal approach 
> seems to be profile for the target locale, which may imply 
> some level of governance or architectural support.
> 
> So, it's not just that reuse and interop are good, but that 
> there are dependency risks to consider plus the engineering 
> cost of all those SHOULDs and MAYs add up. This is why for 
> example, architectural policy in Propylon has always been to 
> make transformation cheap as possible rather than hold 
> unjustified expectations about standard models and format reuse.
> 
> Having said that, where I am seeing reuse working in is the 
> Irish eGov scenario Sean is involved with (some of the RIGS 
> have popped up here recently). The essence there is to to 
> profile existing standards and ensure the architecture 
> supports those who would use standards. Sean might have a 
> more nuanced view on this, but it seems to me without astute 
> profiling, good IT governance, and architectural support for 
> standards, format/schema reuse is fraught.
> 
> cheers
> Bill
> 
> *  such as xAL, WXS  (or even ISO8601)
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org 
> <http://www.xml.org>, an initiative of OASIS 
> <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
> 
> 

• Prev by Date: Re: Partyin' like it's 1999
• Next by Date: RE: Partyin' like it's 1999
• Previous by thread: FW: FW: Partyin' like it's 1999
• Next by thread: RE: Partyin' like it's 1999
• Index(es):
  • Date
  • Thread