RE: [xml-dev] Include data that may be objectively generated some day?

["Len Bullard" <cbullard@hiwaay.net>]

The wildcards of XML for consumers are #IMPLIED and *.

In a minimal schema, those are producer cards to play and consumer cards to
deal with getArribute as the cost to maintain the loose couplings if one
can't expect the managers of the information to read the contracts and their
citations.  If you build for stupid, systems complexify and that's a curve
you can follow to rate staff costs because as the complexity of the tool
rises to offset the incompetence of the user, so does the cost of training
as well as a limit on the available human resources.  

It is cheaper to maintain an organization that uses simpler tools more
intelligently.  Most sharp start-ups know this.  Big organizations lose
touch because as the size of the staff increases, the intelligence goes
down.  So the bet for the tool vendor selling the seat is to make it
general, so complex.  This is evolutionarily sound as a market strategy
because you get to sell more to less sophisticated users of tools
(the-no=choice bits).  

However, failure to own such is not a measure of intelligence. 

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@lists.xml.org
Subject: RE: [xml-dev] 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@lists.xml.org
Subject: Re: [xml-dev] 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.
>
>