Re: [xml-dev] Include data that may be objectively generated someday?

[cbullard@hiwaay.net]

And the domain of "own" is the definition assertion to explore.   
Publishing is weakly constraining for processes that are synchronous  
vs asynchronously scheduled.  In one there is a binding order across  
processes over time (a synchronous schedule).  In the order, there is  
a single point in time load and consume or asynchronous schedule.

Traditional document production systems had defined/contractual  
consumers.  Web systems don't always have that.  Open-ended publishing  
is a key to why Postel is important.    Open Network scaling.

Contract scaling, a la traditional publishing and close-in  
organizational publishing can apply a different model.

In closed chains, you can exploit binding order to get efficiencies of  
production that are critical to information that arrives  
asynchronously by emphasizing least binding as say vs late binding.   
It is easy to use iterator classes to build up markup in  
version/state-marked xml where each transform executed maps to the  
business or other organizational process in the schedule.

I believe this thinking is sometimes called 'enterprisey'.  Network  
theorists use the term disparagingly but when implementing inside one  
to automate one, this thinking helps put predictability back into the  
design requirements.

len

Quoting Mike Sokolov <sokolov@ifactory.com>:

> 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.
>>
>>
>