|
PureBytes Links
Trading Reference Links
|
*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 <sfclimbers@xxxxxxxxx> 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
------------------------------------
Please note that this group is for discussion between users only.
To get support from AmiBroker please send an e-mail directly to
SUPPORT {at} amibroker.com
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
For other support material please check also:
http://www.amibroker.com/support.html
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/amibroker/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/amibroker/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:amibroker-digest@xxxxxxxxxxxxxxx
mailto:amibroker-fullfeatured@xxxxxxxxxxxxxxx
<*> To unsubscribe from this group, send an email to:
amibroker-unsubscribe@xxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|