Re: [xml-dev] XML mantra, from Sean McGrath

[cbullard@hiwaay.net]

I agree.  It depends on one having control of the tool purchase and  
the power to change designs without getting in hot water.  This is not  
always the case.

In fact, I use XInclude to take advantage of the depth and select  
partials.  It makes no difference to the end result but it reduces the  
process cost so I don't have to strip out pieces when building an  
aggregate.  My only point is the need to preserve options based on an  
understanding of fundamentals.  I can make it work either way by  
moving processes into the FOSI and paying the cost of reduced  
re-applicability of the FOSI. That is an interesting topic on its own  
merit:  where in a pipeline of style sheets, transforms and program  
code is the best place to do certain tasks (say style sheet  
contributions).  How does the tool mix affect those decisions?  For  
example, I've never needed to use XQuery; it's good tech but when  
building books in contrast to building a web site, I've never needed it.

Then there are the extensions one can make because one knows how to  
build tools as needed.  Sometimes the trade-off is not individual  
skills but the aggregate skills of the enterprise or group one works  
with.  Smarter monkeys who work carefully can go very fast with light  
metadata collections and flat files.  For a small effort, this is  
optimal.  For a big distributed project where skills are uneven and  
perhaps unpredictable or variable (say high turnover), one may want to  
do the SharePoint/Process thing and sacrifice speed for consistency.   
It's a good tradeoff until the snake swallows a basketball and  
quantity becomes the enemy of quality.  Now adaptability (a plan B or  
C that can be fielded and mastered fast) is desirable.

XML can be beaten by simpler data structures in certain applications.   
But when you have to adapt for changing environments or situations,  
it's hard to beat its semi-structured stringiness given the ability to  
apply cheap tools and stupid pet tricks to achieve results at lower  
costs and good reliability.  A key part of Sean's mantra is early and  
as often as possible.   XML on the front end can be uncomfortable but  
once past the learning curve and tool configuring, it picks up  
production speed fast and maintains it.

A bad schema can blow all of this to hell. ;)

len

Quoting Liam R E Quin <liam@w3.org>:

> On Tue, 2014-01-07 at 12:59 -0600, cbullard@hiwaay.net wrote:
> > [...]
> > d, there are lines not worth crossing.  XI:INCLUDE is
> > one.  If DOCTYPEs aren't a problem and the modules are consistent,
> > entities work just fine, cheaply and for less programming.
> This of course depends on your environment. E.g. some commonly-used XML
> processors (including libxml) support XInclude out-of-the-box.
>
> [...]
>
> > IOW, we often are hired to use the tools at hand and we have to be
> > sharp enough to do that.
> It's a trade-off - sometimes introducing new tools is a better answer
> and soemtimes it isn't.
>
> Liam
>
> --
> Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
> Pictures from old books: http://fromoldbooks.org/
> Ankh: irc.sorcery.net irc.gnome.org freenode/#xml