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

Ken says: "Q: How is XML like violence?
A: If it isn't working for you, then you aren't using enough of it."

Usually true.

I'm slowly but surely being convinced that SharePoint-As-CSDB is actively harmful. It creates a lot of human process overhead and loopbacks for the sake of bean counting and avoiding XML. It looks smashing somewhat like certain British sports cars (and some American: say Corvette) but for all the muscle and flash, the nimbleness is lost. To use another metaphor, it's winning a season in the weight room only to face a team that is small, fast and doesn't have to huddle before every play (say endless meetings). And once set up, if there are errors, dammed hard to rethink.

On the other hand, 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.

It isn't always the case that the organization has the right tools and in these cases understanding XML-Out-Of-The-Box is a big help. There is a presumption in some specs and projects that the web tools are the only or best way to get jobs done. When building Off The Web products, those presumptions are actively harmful.

Then there is the FOSI. It is supposed to be dead but it only smells funny. I've looked at the processes people are using to build S1000D documents using XSLT pipelines and they are a lot of work where a FOSI can do the job with fewer lily pads as long as you have an editor that can produce the output format (say PDF). Now if the XSLT tools are the tools at hand (say the Github style sheets) and you are happy with the dm-to-db-to-docbook-to-FO-to-pdf steps, have at. It simply isn't necessary. A FOSI can do the job in a single bound.

Then there are the assumptions of the schema designers. S1000D's dmRef is an example. It's a way to annotate the morphology but as an identifier, it isn't useful and assumes post-processing. It's way to store the components of identifiers but it's like tossing a relational table into the middle of a table of contents and saying "figure this out in situ". So we toss code at that and it works but it means a publication module is worthless without the extra code. An XML document with a set of proper entities works out of the box. YMMV but it means avoiding some S1000D bits like the PM until you have to pass it along and even then, you're passing on the problem to the next guy.

IOW, we often are hired to use the tools at hand and we have to be sharp enough to do that. This is really what distinguishes the experienced experts from the resume experts: knowing the difference between XML and systems that use XML. The Web IS A System. Full stop.

As said, horses for courses.


[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