[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Include data that may be objectively generated some day?
It was still the right bet. Future proofing is almost as bad past proofing. That you can build a system now doesn't mean your consumers should have borne the costs. It's just wrong. I learned the error of that by being the one to put HYTIME link constructs in US Navy specifications. Oopsie. len -----Original Message----- From: Cox, Bruce [mailto:Bruce.Cox@USPTO.GOV] Sent: Wednesday, November 30, 2011 5:16 PM To: Mike Sokolov; John Cowan Cc: cbullard@hiwaay.net; Costello, Roger L.; xml-dev@l... Subject: RE: Include data that may be objectively generated some day? When designing the DTD's for published patents, we included markup for well-defined constructs specified in the rules for patent filing, examination, and granting. Some of that markup was speculative, in the sense that there were no systems in existence that would exploit the markup. Consequently, the contractor converting content to XML for publication was instructed to not apply some of the markup, purely for the cost benefit. Ten years later, we're building systems that would have exploited that markup, were it there. Can't win them all. Bruce B Cox OCIO/AED/Software Architecture and Engineering Division USPTO -----Original Message----- From: Mike Sokolov [mailto:sokolov@ifactory.com] Sent: 2011 November 28, Monday 17:45 To: John Cowan Cc: cbullard@hiwaay.net; Costello, Roger L.; xml-dev@l... Subject: Re: Include data that may be objectively generated some day? How about: don't publish what you don't own? Publishing schemas that include meaningless definitions has an analogue in software development, which is writing untestable code: ie code designed to handle a circumstance that has not yet occurred and may never occur. It's always a bad idea. Seems to be generated by people with clever ideas about future-proofing, but it seems as if we are wrong more often than not about where the future is headed. One practical approach to dealing with this tendency is to insist that any schema definitions be backed up by requirements, functional specifications, sample data and use cases, together with tests to prove the data functions as intended in at least some dummy test environment. Just like real requirements! The proponents either pay the freight, if the feature is really deemed to be important, or it gets dropped as low priority. -Mike On 11/28/2011 04:11 PM, John Cowan wrote: > cbullard@hiwaay.net scripsit: > > >> Don't make law you can't enforce. Don't create requirements you >> cannot prove are necessary to the consuming process. >> > Well, that's fine if you know what the consuming process is, or at > least what it expects. But often you don't: you are publishing, and > you don't know who will subscribe. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|