OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] XML mantra, from Sean McGrath

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


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS