Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: [xml-dev] [Summary] Creating a single XML vocabulary that is appropriately customized to different sub-groups within a community

From: Len Bullard <len.bullard@---.--->
To: Fraser Goffin <goffinf@----------.--->, xml-dev@-----.---.---
Date: 7/17/2008 6:01:00 PM
There is, Fraser.  The tradeoff is doing it upfront when all one has is hope
vs doing it later when one has requirements.  Sometimes one is advised to
write a one-off validatible document exchange.  Sometimes one needs to write
a message server.

The problem is delivering a promised item six weeks before the standard is
released to draft.   Even where one knows there is a market that needs a
standard set of message types, timing is everything.

Traffic analysis and use cases should precede schemas.  I don't think that
is controversial.   I'm not sure it makes sense to start with a single
customizable vocabulary unless the traffic analysis indicates it can be
fielded in quick time regardless of what the use cases suggest.  IOW, don't
take the designer's word for it.  Look very hard at the differentiation and
rate of divergence in the subtypes first.

If the traffic suggests there is a wide variation in the names for example,
it can be best to wait for that single language and build a message server.
The counter argument is the standard can force convergence.  The counter
counter is no one accepts force as long as a vendor will build the one off.
The path of least resistance overcomes globals.  So unless it really is a
Nash equilibrium, guys say and do anything to get the girl.

Outcome:  like Microsoft, you end up with VML or that early schema
contestant and forced to support it for years, or like Sun locked in an
internal battle for years over the costs of keeping Java proprietary.

len


From: Fraser Goffin [mailto:goffinf@g...] 
Sent: Thursday, July 17, 2008 11:05 AM
 
> In practice, the cost of local agreements is cheap.  Global agreements are
> not.

Much of the time this may be true, however there is also a 'tipping
point' where managing every customer contact as a unique interaction
can also be costly and consume resources that would otherwise be
available for other things (too many people standing around sticking
their fingers into holes to stop the leaks = business paralysis).

Its a bit like agile development. Cruft up some code to pass your
tests (you all practice TDD right ;-), then refactor (i.e. one aspect
of which is to remove duplication).

I'm not saying that maintaining a market sector standard is easy, or
that it won't constrain busiess operations if followed too
puritanically, but imho there *is* some utlity to be had by apriori
agreement.

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent