1. Given that it's not actually XML, no need to include the <entry></entry> wrapper. That can easily be added during conversion. Just use a blank line between entries.
2. Similarly, you're not really buying anything by using pseudo XML tags for your entries. Won't hurt, but won't get you any closer than Dingo's suggestion. Go with whichever you're most comfortable with. 3. You may want to split apart the name of the argument and the default value (two separate pieces of data). Again, not critical. Just easier parsing later. e.g. <arg_name>period <default>14 Mike --- In [email protected], Dennis Brown <[EMAIL PROTECTED]> wrote: > > *Note: Message trimmed > > Dingo and Mike and everyone, > > Thanks for the input on this. I have studied the pure XML format > example. I don't think it passes my criteria for a human input > format. The format is easy for a machine to parse but not for a human > to parse at a glance. Too much overhead for the eye to reject and > what happens if an item is not properly terminated. It looks to have > too many redundant elements that must be right. It is great for > nesting items, but we do not need that feature. > > The other proposal of just a name and a data item might do the trick > but it will add a lot more lines to each entry making it a little > harder to check the raw data by eye, but it may be worth it. Let me > try to recast my previous examples this way, but trying to meet half > way to XML without giving up the human readable form. Tabbing the > data in alignment makes it easier to read and will make Herman > happy ;) --I hope the tabs come through on Yahoo. An alternative is > to only use monospaced text fonts and space out to the same place in > the template. I don't find mono fonts as readable, but I could go > along with it. > > Before, I was putting all the things on one line that were related so > the order of the lines was not important. Now, the order of repeated > items have significance. The arguments are in the order passed. Must > have an argument type and the optional argument name relates to the > last argument type. Hierarchy order is significant. All data from > the last tab to the EOL is significant text. > > The conversion to XML should be easier now, possibly just a word > processor macro. The AFL conversion to some other text output should > not be any more difficult than before. > > Give me one more round of critique --anyone. > Other special situations or rules that should be considered? > > BR, > Dennis > > <entry> > <entry_name> abs() > <full_name> Absolute value > <description> Returns absolute value of a number or array > <return_type> an > <return_name> array | number > <arg_type> an > <arg_name> array | number > <abdoc_link> http://www.amibroker.com/f?abs > <ukbdoc_link> > <abvideo_link> > <ab_version> 1.0 > <hierarchy> Functions > <hierarchy> Math > <search_tag> absolute > <search_tag> sign > <search_tag> positive > <related_entry> sign() > </entry> > > <entry> > <entry_name> CCIa() > <full_name> Commodity Channel Index of Array > <description> Returns Commodity Channel Index of an array > <return_type> a > <return_name> CCI > <arg_type> a > <arg_name> array > <arg_type> n > <arg_name> period=14 > <abdoc_link> http://www.amibroker.com/f?cci > <ukbdoc_link> > <abvideo_link> > <ab_version> 4.2 > <hierarchy> Functions > <hierarchy> Indicators > <search_tag> CCI > <search_tag> Woodie > <search_tag> overbought > <search_tag> oversold > <related_entry> CCI() > </entry> > > > On Sep 2, 2008, at 7:38 PM, dingo wrote: > > > You can create the list that will be easy to convert to XML or > > anything. > > > > Precede each "piece" of info with a title followed by a special > > character that you won't use for any other reason and keep entries > > on a separate line. > > > > Name| blah blah blah > > Definition| www.gasafa.com > > Example| www.gagasdfwe.com > > . > > . > > > > Name| aasdfasdf > > Definition| www.gasafa.com > > Example| www.gagasdfwe.com > > > > d > > > > On Tue, Sep 2, 2008 at 6:50 PM, Mike <[EMAIL PROTECTED]> wrote: > > Dennis, > > > > An XML template need not be very different from what you have put > > forth. For example; the following might show that the entry "abs" has > > two signatures, each taking a single argument, either a number or an > > array and is described at the given link. > > > > e.g. > > > > <entry> > > <name>abs</name> > > <args> > > <arg>n</arg> > > </args> > > <args> > > <arg>a</arg> > > </args> > > <ablink>http://www.amibroker.com/guide/afl/afl.php?id=3</ablink> > > ... > > </entry> > > > > The advantage being that it delineates the data right up front, > > rather than risking inconcistent entries that would require > > specialised parsing later just to normalize it all. > > > > For example, your entries already have an inconcistency in that you > > do not separate "n" and "a" with a comma for Args and Returns in your > > entry for "abs", but you do in your entry for "CCI". > > > > All it takes is for a few entries to use the comma in Args, or omit > > it in Tags and you will have introduced the need for specialized > > parsing down the road. Having things wrapped right off the bat slows > > things a bit up front, but prevents the need for specialized coding > > or hand edits down the line. > > > > But, Dingo's comment is fair, if you just want to keep the ball > > rolling, then do keep an eye on consistency such that the data will > > lend itself to an easier conversion later. > > > > Mike >
