Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder2.hal-mli.net!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!news.musoftware.de!wum.musoftware.de!weretis.net!feeder4.news.weretis.net!news.teledata-fn.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <7845240.ffiaYbSxCL@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Fri, 21 Dec 2012 19:09:26 +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+&. <9af7f027-c78f-491d-a427-4576adfcc768@10g2000yqk.googlegroups.com> <23YbGkLWbkxQFwXT@invalid.uk.co.demon.merlyn.invalid> <18e8688c-731a-46ce-b81f-bdf3b30e1a5d@10g2000yqo.googlegroups.com> <55e1ad32-a46d-4993-bfc6-423082713114@4g2000yqv.googlegroups.com> <94d85931-0447-446a-b403-124e797ab4da@i1g2000vbp.googlegroups.com> <+idJTVMLvgzQFwH3@invalid.uk.co.demon.merlyn.invalid> <3acb9cd7-70c9-4585-a2b2-bc3c57227f64@c14g2000vbd.googlegroups.com> <010aec15-60d5-41cd-a88d-85c48cd9d230@c14g2000vbd.googlegroups.com> <30142024.jo3loCeJWj@PointedEars.de> <793164ed-f5d8-4950-870a-40df6da2a72c@b8g2000yqh.googlegroups.com> Followup-To: comp.lang.javascript MIME-Version: 1.0 Lines: 79 NNTP-Posting-Date: 21 Dec 2012 19:09:27 CET NNTP-Posting-Host: ab9088a6.newsspool2.arcor-online.net X-Trace: DXC=^K>JgDSZCQoeoCI^f\Y]EaA9EHlD;3Ycb4Fo<]lROoRa8kFYBYU3JEom=nL@40\lbi` X-Complaints-To: usenet-abuse@arcor.de Xref: csiph.com comp.lang.javascript:17788 Scott Sauyet wrote: > Thomas 'PointedEars' Lahn wrote: >> Scott Sauyet wrote: >>> Thomas Lahn proposed something very much like the current XML structure, >>> although perhaps with multiple documents. (It's still not clear to me >>> if he means to have additional documents for supporting material or to >>> make each entry it's own XML file, but that's another discussion.) >> As I explained in my previous posting [1] already, each section of that >> FAQ has its own XML file already. >> [1] > > I'm glad to hear it. But no, I didn't get that out of this: > > |> 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. > > If I had found the change log you were referencing, I probably would > have understood, but I didn't see a file named `changelog.txt` or > similar in the root, and didn't pursue it. Well, I have posted the URI of the (now) master XML resource, and explained the approach I took for splitting up the data, for a reason. I have also already said that there is a link in the generated FAQ document to the changelog. > I'm now supposing you mean the Subversion change log in the repository > mentioned earlier, which I've since visited. What else. AISB, there is a link to the changelog *in* the “FAQ for comp.lang.javascript”, and it is at the top of that generated document. > Now I see better what you're doing. Good. > I assume it's different for you running these locally, No, nothing is run separately anymore. While I do test locally, the HTML document is generated *on the fly* from the XML data, by transforming XML to HTML according to the templates defined in the XSLT stylesheet. > but when I view the referenced `index.xml`, I see only the shell. Whereas with “shell” I assume you mean the CONTENTS element. You could say that is a bug in the XML view of browsers. I have seen it in Chromium 22. + is your friend. > The document entities are not resolved, They are (wrongly), that is why no content is displayed. > and the node is empty. The index.xml resource is not intended to be viewed directly, it contains just the *data*. It always has, only now most of the data is referenced instead of included verbatim. PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16