> Marcus Carr wrote:
>
> > Not me - conversion work of legacy data routinely involves pulling documents
> to
> > pieces, working on a fragment (such as a table) then putting it all back
> > together.
>
> I'm not sure I understand. We want to give an authoring tool/XSchema
> explorer/etc. a way to determine the roots of useful/possible documents.
It's the "etc", that I wonder about - it seems that the focus of XSchema is being
narrowed to a point where some "etc" will not be able to make use of XSchema without
violating the intent. The problem is that the intent may not have accounted for a
slightly different processing model - might the same application require multiple
XSchema for different tasks, or would you design them more loosely to reduce
redundancy? This would seem to be a subjective call and a natural for protracted
discussion.
> I don't understand what this has to do with working on the individual fragments
> of a document.
It's not so much about working on fragments as it is ensuring that current, common
data handling processes aren't locked out of using XSchema because we aren't looking
around enough. The narrower the range of uses XSchema is appropriate for, the less
chance of it succeeding.
-- RegardsMarcus Carr email: mrc@allette.com.au _______________________________________________________________ Allette Systems (Australia) email: info@allette.com.au Level 10, 91 York Street www: http://www.allette.com.au Sydney 2000 NSW Australia phone: +61 2 9262 4777 fax: +61 2 9262 4774 _______________________________________________________________