Look Jenda-dude, your not telling me anything I don't already know here, and comparing aXML with Perl itself is not a fair or valid comparison. I know I started it, but only as a means to try and introduce a new thing which works in a completely different way, by relating it to concepts of which your already aware.
A fairer comparison perhaps would be comparing aXML with something like TT2, however once again this is comparing apples and oranges, since TT2 has a limited domain-specific language for controlling document layouts, where aXML has a simple an open ended syntax which by virtue of that fact tha t definition files are coded in perl, is turing complete and far more expressive.
I understand that it's difficult to see what I'm saying clearly using only what I have typed up for reference because I'm struggling to find ways to effectively communicate the concept. That's not entirely my fault either because aXML is not like anything else that I have ever come across and the comparisons usually fail to clearly express the situation properly.
aXML has no conditionals, variables, loops or operators, all it concerns itself with is abstract symbols and their correct processing order. From the very simple ruleset you can derive huge complexity in very neat, understandable and reusable code.
Now sure, you could obfuscate the hell out of it...
(j34)
<hhrhe>gghheh</hhrhe>
<fdkes>adalekaeka</fdkes>
<asdj3>
[sdf]
<sdkjer>aksdjke</sdkjer>
[/sdf]
</asdj3>
(/j34)
The above represents a VALID aXML expression, which aXML can process, given a plugin set which corresponds to the symbols. What does it do? there is no way to know however you can infer that :
- j34 is the first plugin to be run
- j34 takes 3 arguments
- sdf is passed through, and is computed last. Indeed it's probably replicated by a loop inside the code of j34
To know what the above does you have to know what the plugins do, which is why I recommend using descriptive tag names rather than obfuscated ones, but that's really upto you, there is no limitation on what you call your symbols or what they do. The symbols can even modify each other and the document as a whole at runtime, a feature I have exploited in previous projects.
To give another example, consider this:
(case c="(qd)foo(/qd)")
<bar>
[inc]bar[/inc]
</bar>
<baz>
[inc]baz[/inc]
</baz>
(/case)
The above has exactly the same result as :
<inc>(qd)foo(/qd)</inc>
or
(inc)(qd)foo(/qd)(/inc)
or
[inc][qd]...
or
[inc](qd)...
or
<inc>(qd)...
However you might want to use the case statement instead if you want to catch an error such as qd->foo containing a value which links to a file which doesn't exist..
(case c="(qd)foo(/qd)")
<bar>
[inc]bar[/inc]
</bar>
<baz>
[inc]baz[/inc]
</baz>
<else>
[inc]wtf[/inc]
</else>
(/case)
This would be the same as saying :
given ($foo)
{
when (/bar/)
{
return get_file('bar');
}
when (/baz/)
{
return get_file('baz');
}
default
{
return get_file('wtf');
}
}
Again there is always a mapping, but sometimes it's hard to see what that mapping would be for instance;
<case c="(qd)foo(/qd)">
(inc)cases(/inc)
</case>
Where the file "cases" contains the code which was previously in the case tag, but now is added in dynamically prior to the case tag executing. The result is the same, however I cannot imagine how you could do that normally (that's not to say you can't, just that it probably requires a higher level of perl mastery than I currently have, and definitely a higher level of mastery than is needed to achieve the same result quickly and easily in aXML. |