Ours & Hippy — le blog Ours & Hippy ourshippy@huoc.org tag:blog.huoc.org,2009:atom 2010-04-18T22:03:29+02:00 tag:blog.huoc.org,2010-04-18:comments/1271621009.30221 Re: Not dead yet: xmltools, long after the summer 2010-04-18T22:03:29+02:00 2010-04-18T22:03:29+02:00 Pierre Bourdon (Pierre Bourdon) <p>Did not find this story boring at all&#xA0;:) . Please keep up the hard work on this project, I can think of at least 42 tasks where xmlgrep and xmlsed could be very helpful (for example, I would really like to be able to create an intelligent grep for C files which works on the code AST instead of lines)&#xA0;! </p><p>By the way, I&#x2019;ll try to find some time during next week to create a xmltools-git package on AUR (Archlinux User Repositories).</p> tag:blog.huoc.org,2009-10-20:1256074616.13991 Re: xmlsed prototype 2009-10-20T23:36:56+02:00 2009-10-20T23:36:56+02:00 Nobody (Nobody) <blockquote><div><p>This will work as expected. </p></div></blockquote><p>Indeed, and this is as described in <em>xml_pattern(7)</em>, that I should have read more carefully. Sorry about that. </p><blockquote><div><p>it’s just that I have a lot to work on and other areas need attention right now </p></div></blockquote><p>As I said, I understand that.&#xA0;:) </p><blockquote><div><p>Anyway, have you tried xmlsed a bit or toyed with more advanced features (subpatterns, groups, etc.)? </p></div></blockquote><p>I did tried xmlsed, and it worked fine. (And I wish this tools had existed three years ago, I bet it could have saved me some headaches when I was then trying to handle inconsistently structured XML files!) </p><p>But in both cases, I didn’t try (yet) anything overly complicated, only some simple tasks that only require quite simple statements.</p> tag:blog.huoc.org,2009-10-20:1256025293.11318 Re: xmlsed prototype 2009-10-20T09:54:53+02:00 2009-10-20T09:54:53+02:00 rz0 (rz0) <p>Well, it&#x2019;s not that it doesn&#x2019;t handle prefixes, it&#x2019;s more like&#x2026; as I was saying in the post, the syntax is a bit of a mess. You can only use the short name predicate syntax with alphanumeric names; if you want to match anything else, you have to write it like this: </p><pre><code>$ xmlgrep '$=&quot;prefix:a&quot;' </code></pre><p>This will work as expected. I know the syntax is pretty obscure; aside from me, there is probably nobody who knows the entire syntax, actually. Even David writes suboptimal patterns from time to time.&#xA0;:) </p><p>About the &quot;two-way match&quot; feature, I&#x2019;ll see if I can do something about it, but it&#x2019;ll probably have to wait. It&#x2019;s not that it&#x2019;s hard to do, it&#x2019;s just that I have a lot to work on and other areas need attention right now (e.g. getting the syntax to something that people will actually be able to use without telling me &quot;I can&#x2019;t do that&quot; while in fact, they can, only it&#x2019;s hidden somehow). </p><p>Anyway, have you tried xmlsed a bit or toyed with more advanced features (subpatterns, groups, etc.)? </p> tag:blog.huoc.org,2009-10-19:1255987782.11318 Re: xmlsed prototype 2009-10-19T23:29:42+02:00 2009-10-19T23:29:42+02:00 Damien (Damien) <p>Unfortunately, it seems that xmlgrep currently does <em>not</em> recognize any node whose name contains a namespace prefix. </p><p>Here is the simplest test case. Without namespace prefix: </p><pre><code>$ xmlgrep a &lt;&lt;&lt; '&lt;a/&gt;' &lt;a/&gt; </code></pre><p>And with a dummy prefix: </p><pre><code>$ xmlgrep 'prefix:a' &lt;&lt;&lt; '&lt;prefix:a/&gt;' </code></pre><p>As for the two-way match that you suggest, yes, that’s exactly the behaviour I would love to see.&#xA0;:) </p><p>My problem is, I’m not always the author of the XML files I have to process, and I don’t know in advance what prefix the author had associated to a particular namespace. So it would be very nice if I could just invoke xmlgrep as follows </p><pre><code>$ xmlgrep -n &quot;prefix=http://www.example.org&quot; \ 'prefix:a[prefix:b/.=&quot;2008&quot;]' file.xml </code></pre><p>and have it “do the right thing” even if in file.xml, the namespace &quot;http://www.example.org/&quot; is associated to another prefix. </p><p>Of course, I realize this is not a trivial feature to implement, and if you don’t see a point in it, I will understand that you focus on what matters to you.&#xA0;:)</p> tag:blog.huoc.org,2009-10-19:1255978946.11318 Re: xmlsed prototype 2009-10-19T21:02:26+02:00 2009-10-19T21:02:26+02:00 rz0 (rz0) Thanks for the comment. As for XML name spaces, what special treatement would you expect? At the moment, name spaces are not treated differently from other elements, you can just match them as prefixes. Of course, this completely ignores the URI specification associated with the name space prefix, but in my opinion, having to match the URI rather than the prefix would be way too verbose and impractical for most uses. We could imagine more complex schemes like a two-way match; e.g. I specify that prefix <code>X</code> stands for <code>uri_X</code>, the document specifies <code>x</code> be used for <code>uri_X</code>, and the parser automatically converts node predicates in patterns from <code>X:whatever</code> to <code>x:whatever</code>. But the question is: is that useful enough to justify the added complexity? Do you have a precise use case in mind? tag:blog.huoc.org,2009-10-18:1255887161.7462 Re: xmlsed prototype 2009-10-18T19:32:41+02:00 2009-10-18T19:32:41+02:00 Damien (Damien) <pre>Hello, Very promising tools. I tested them for a while on my own XML files, they worked pretty nice. :) Do you plan to add support for XML namespaces?</pre>