Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.teledata-fn.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <3277590.iR7sza6qQi@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Wed, 19 Dec 2012 22:54:01 +0100 User-Agent: KNode/4.4.11 Content-Transfer-Encoding: 8Bit X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. <1868da91-d142-49ee-8b09-27c0983c1af4@a2g2000yqh.googlegroups.com> <1463892.vp2pE7osQE@PointedEars.de> <2715826.m0UDekTA75@PointedEars.de> <15797403.gaI5B2VX2m@PointedEars.de> <1820492.ZBGHdalzjF@PointedEars.de> <3703984.pIQAaQtanI@PointedEars.de> <22ca6ccc-0ddd-40df-b852-9d9c9f43c88e@w8g2000yqm.googlegroups.com> Followup-To: comp.lang.javascript MIME-Version: 1.0 Lines: 79 NNTP-Posting-Date: 19 Dec 2012 22:54:03 CET NNTP-Posting-Host: 4ea5183f.newsspool2.arcor-online.net X-Trace: DXC=PY`;fY4T=\oPKPPVf;4hUjA9EHlD;3Ycb4Fo<]lROoRa8kFboJ3iJIEl65b X-Complaints-To: usenet-abuse@arcor.de Xref: csiph.com comp.lang.javascript:17778 Scott Sauyet wrote: > Thomas 'PointedEars' Lahn wrote: >> Scott Sauyet wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> Scott Sauyet wrote: >>>>> [T]he main goal from my point of view is to have a maintainable FAQ. >>>>> I'm willing to break with the existing infrastructure if doing so will >>>>> make this goal easier. >>>> A fundamental misconception. Breaking with an existing infrastructure >>>> can by definition only make an implementation task *harder* because you >>>> will also have to build your own, new infrastructure then. That does >>>> not mean that the end result could not be *better*. But it requires >>>> more effort than building on something that already exists. As a >>>> result, it requires more man-hours to become at least adequate to what >>>> is intended to be replaced. >>> Nonsense. Writing a tool that automates a tedious manual job breaks >>> existing infrastructure. >> I have no idea what you are talking about. Have you? > > Yes, I was discussing ways to make it easier to maintain the FAQ. But AISB, the question is what one considers more important. Is it going a longer way to devise the perfectly easy, future way to maintain the FAQ? Or is it reusing the existing content and data with much less effort so that there is a usable FAQ right now (that can be improved later, even rather easily transformed to Markdown-ish formats with XSLT)? Both approaches have their advantages, but in a (so far) one-man project I certainly prefer the latter approach. Insofar improving an existing FAQ is fundamentally different from writing script libraries or doing research, although JSX and the ES Matrix are (so far) one-man projects (with valuable contributions from others) as well. >>> My contention is that having multiple documents in a plain-text format >>> such as Markdown will make for an easier to maintain FAQ than having a >>> single XML document containing the entire contents. >> I have already explained that it does not have to be that way with XML. >> Why are you insisting on the false dichotomy? > > You did mention say that such was a possibility. But what you've > presented so far, at least when I looked at the SVN repository, was to > keep the single XML document. Is this not the premise on which you're > proceeding? AISB, I am doing this iteratively, and since I have begun to follow SVN recommendations [1] more strictly recently, I try to keep my commits atomic (also so that those interested can better see what I am doing). > I think it would be a step forward to create separate documents for > each FAQ entry. But that seems contrary to the approach you've > presented. Am I misunderstanding? Yes, see and the changelog. I did not expect it to be that easy, though. I was experimenting tonight with an “include” element¹, when I remembered to have seen the “Process XML inclusions” setting in Eclipse WTP (whose XML editor turns out to be very helpful) [2] while setting up local Validation there. A quick Google search for “xml include” showed the better solution [3] then. PointedEars ___________ ¹ The “include” element would have had a template in the XSLT stylesheet to use its “src” attribute, which was passed as parameter to the “document()” function. That did work, basically. [1] [2] [3] -- Use any version of Microsoft Frontpage to create your site. (This won't prevent people from viewing your source, but no one will want to steal it.) -- from (404-comp.)