in reply to Transforming axml into hyperlinks

This thread is my first introduction to "aXML". I presume the "definitive" reference would be here, which makes it look like a commercial product (first warning signal) with an obvious MS/ASP/.NET focus (another yellow flag). If this is one of those "extensions" to XML syntax -- intended to give the buyer "special powers" not conferred on those who insist on compliance with openly agreed-upon standards -- it is a misguided pursuit.

That said, how is it possible that angle brackets can be embedded in an attribute value, without being converted to  < > ? Is that prudent? And why would a "qd" entity be embedded immediately inside another "qd" entity? And why would there be up to three different ways of bracketing this "qd" sort of thing (whatever it is)?

And what does this have to do with Perl?

Update: Sorry -- I over-reacted there. Seeing the perl part of the question:

axml string: 
<link action="<qd><qd arg="(qd)ref3(/qd)">ref2</qd></qd>">[qd]ref[/qd]
+</link>

[download]
How could one obtain the result: 
<a href="action.pl?action=someaction">a link</a>

[download]
using conventional cpan modules?
I guess Text::Balanced might be a way to start, but really, you might just have to go straight to Parse::RecDescent. But I'm not sure you've given enough of the "motivating principles" to clarify what it is you really need. Based on what I understand from the OP, this would do it: 
s{<link action=<qd>.*?</link>}{<a href="action.pl?action=someaction">a
+ link</a>};

[download]
That goes against the PM grain of using XML parsing modules when parsing XML, but this doesn't really look like XML, so why worry about it?

Replies are listed 'Best First'.
Re^2: Transforming axml into hyperlinks
by simonodell (Acolyte) on Apr 15, 2007 at 04:49 UTC

    No, the term aXML is used by others for different meanings, there is no definitive reference, sorry i didnt think about people who havent been watching my sorry display for the last few days...

    My aXML is completely opensource, but my code is way too ansi c, and not perl prose enough for most peoples liking. Anyway I'm looking into doing it right and to do so I need information. Problem is I don't know what information I need, hence I'm trying to explain what aXML does in the hope someone on the other side can shed light on the path for its future development.

    Read more... A quick aXML tut (947 Bytes)

    UPDATE: Looked at Text::Balanced, very interesting i will study it properly and look into using it for the next version.

[reply]
[d/l]
      Okay... I think you're getting ahead of yourself a bit with the embedding and ordering. First off, your using "special" tag delimiters (parens and square brackets) that have some greater-than-zero probability of showing up as actual text data in a given chunk of typical content.

      How are you going to know (decide) which parens (brackets) are wrapped around your special "axml" symbols, and which are (normal) chunks of actual text data? And what's going to happen when the text content itself -- independent of any added axml markup -- contains unbalanced parens (which happens more than you might want to admit.

      Aren't you running a risk, of indeterminate but non-zero probability, that "name space" collisions will occur? That is, the names being assigned to your special replacement placeholders are going to have to be distinct from whatever might occur as actual data (e.g. tokens that might occur between parens or square brackets).

      And that's all distinct from the problem of the complexity imposed on the content when you start talking about embedding/nesting replacement strings, and forcing precedence relations based on parens vs. square brackets vs. angle brackets. I can't get my head all the way around it, but I can foresee clashes in store... an angle-bracket style directive inside a paren-style directive, etc.

      The task you're trying to accomplish with this mechanism can't be all that complicated. It's not just the fact that it never would be; I think it's also a matter that if it were that complicated, you'd need a different mechanism to make the control of it comprehensible to humans.

[reply]
      aXML allows for 2 types of non-standard bracket delimiters, ( ) and 
[ ],  Which mean respectively, process this tag before all others, and
+ process this tag after all others.

      [download]

      Please don't take it as a personal offense, but it this a wise choice to begin with? Personally I see problems with it:

      1. clashes with parens and squares in the text, as already pointed out by graff;
      2. creation of something that is somewhat like XML, but in fact is not.

      Now, as far as the second point goes, it if were compellingly necessary, I don't think it would be a problem, although it would still leave you with the need to invent a wheel only slightly different from those that are already available, and thus to reinvent many wheels. Or to take existing tools, understand how they work and modify them to suit your needs, which would save you considerable time and give you more guarantees of doing the Right Thing™ but would still be less trivial than one may naively expect. Even without that, the approach is somewhat inelegant. XML is not exactly "simple", and I'm not really a big fan of it, but it has an elegance of its own. Having three different breeds of tags strikes me as breaking that. If the tags still have to nest correctly, you could achieve the same thing with attributes. Granted, it would be more verbose, but since you're dealing with "a sort of XML" anyway, that should not be a concern. Otherwise you would be using a lwml instead. If you go with attributes, then you will have regular XML and you could use one out of many already existing tools to parse XML.

[reply]
[d/l]

In Section Seekers of Perl Wisdom