in reply to Re^10: aXML vs TT2
in thread aXML vs TT2

The problem isn't with quotes. You used a poor metaphor, so I provided a better one. The problem is that aXML can't

aXML doesn't need an escape character, it doesn't try to distinguish code from data, in aXML code and data are one and the same.

Wrong, that's the really really really really big problem we're talking about, wrong.

Did you forget what we were talking about?

aXML needs to be able to distinguish a <d> it must process (code) and one that it must pass through (data).

With regard to your other point, in aXML the only difference between <foo bar="moo"></foo> and <foo><bar>moo</bar></foo>

In my examples, foo isn't a plugin. Please reread with that in mind.

Replies are listed 'Best First'.
Re^12: aXML vs TT2
by Logicus (Initiate) on Oct 22, 2011 at 07:50 UTC

    You still didn't answer my question... why is that so bad in this context/paradigm? I'm sorry but I'm not just going to take your word for it, especially when what your saying is flying in the face of years of experience of developing complex apps in aXML. I don't care if you taught Larry himself everything he knows about programming, you can't just tell me my experience is wrong without providing qualification to your statements. I doubt you would just accept my word on such a matter if it contradicted something you are well experienced with and know to be true.

    If <foo> is not a plugin then the parser will have nothing to do with it, hence you can structure it however you please and there will be no effect. aXML only acts upon correct well formed tags which it can recognise, everything else is expected to be codedata intended for another parser (I.E the parser in the client browser) and simply passes straight through untouched.

[reply]
[d/l]

      You still didn't answer my question... why is that so bad in this context/paradigm

      Are you seriously asking what's wrong with a template system that cannot output "<d>" when you want it to? It's the very definition of failing to meet its requirements.

      If <foo> is not a plugin then the parser will have nothing to do with it, hence you can structure it however you please and there will be no effect.

      Are you saying one can use "<foo/>" for non-plugins? That's not too bad, then. I wonder how you did that without introducing any other bugs, though.

[reply]
[d/l]
[select]

        Are you seriously asking what's wrong with a template system that cannot output <d>

        No I'm not, because you can output <d> if you want to. You can use any combination of ascii characters you like, and they will passthrough untouched, unless and only unless, those characters represent a valid and recognised tag to be executed.

        In this case, <d> is used by the <db_select> plugin, it's not a plugin itself. If you find a <d> which is inside of a <db_select> tag, then it refers to a selected column, outside of that scope it has no meaning at all.(unless you give it one)

        That definition is also not set in stone (very little is in aXML), the <db_select> plugin itself blesses <d> with it's meaning, and it would be quite trivial to update that plugin to use a different token to delimit column names. You could also make it so that <db_select> takes an extra attribute argument to tell it what constitutes a delimiter within it's scope.. I.E:

        
  <db_select delimiter="FFF">
    <query> SELECT * FROM users</query>
    <mask>
      <FFF>username</FFF><br>
      <FFF>email</FFF><br>
    </mask>
  </db_select>

        [download]

        There is no limit on how you the designer choose to design your system, it's completely soft coded. You could even do something really esoteric like shove a bunch of jpeg data through it with tags embedded in it which output jpeg data I.E:

        
sajhfihjufoasd7f83k4jnrjkysaolifgdf
dfydzsxifnyesafqvp3ruioasdcidsfgsdr
uvf<XXX>hello there</XXX>sd'fo8sdfd
0df8sdfksjfd9s8j54rowfskf78susdyvns
7nyrv09sf7nusp98mfs9dfjksdlfewssdkf

        [download]

        The upshot being, you now have a way of dynamically generating JPG images. Why you would want to do that is beyond me, but it should be possible (I have not tested that theorem)

        I think perhaps if you understood where I'm coming from with this it might help, when I was 17 and still wet behind the ears, I spent most of my college life hacking away at graphics demo's in C instead of doing my (boring) COBOL assignments.

        I think in a certain way as a result, everything is ultimately data, the computer itself works only with binary and makes no distinction between data and code, that distinction only applies to how we humans think about what we are doing, it's an abstraction to help us out, not the computer which doesn't care. In aXML that abstraction is just not relevant since in aXML data is code and code is data. The structuring of the codedata in terms of the recursive nesting heirarchy of valid tags is all that matters and all the parser concerns itself with.

        It doesn't matter if your dealing with a load of pixels or a load of ascii, ultimately it's just numbers which either do or don't have structure, and either do or don't represent valid declarations.

[reply]
[d/l]
[select]

In Section Meditations