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 <>:
> On Tue, 2014-01-07 at 12:59 -0600, 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
>
>
