|
PureBytes Links
Trading Reference Links
|
Mike,
Thanks for the feedback.
1. I thought <entry> might make it a little easier to parse for my own
purposes and one less thing to convert.
2. My thought here was that we might as well all call things by the
same consistent names. I couldn't come up with a character to
terminate the keywords with that would look good and not be used in
some part of the data, so I just went with the <key_word> form. The
alternative was the EOL+keyword as the form, but that is no different
to parse since "<key_word>" becomes the keyword.
3. I had not thought of this extra default data item. I was just
thinking that the parameter name was whatever text to display --not
that a default would ever be parsed out separately. However, there is
no harm in specifying it the way you suggest, and it might be useful
in other output formats. So yes, lets do that.
The final form of the text database will be a bunch of text elements
that can be assembled into whatever useable document we wish.
Here is my proposed list of data items and what they are used for
(below). Practically every item is optional except <entry_name> and
<hierarchy>. There are a lot of items, but only the ones that make
sense for an entry need be included. Potential ones can be left in as
a template and left blank for now. Missing or blank items would be
parsed to logical defaults. I like leaving things flexible. If a
future need is found for another data item, it can just be added where
desired without any effect on previous parsers. As reinsley said, it
could end up being the backbone for helping users quickly find
relevant information scattered through different web resources. It
never hurts to look at the moon... even if we cant jump that high today.
Any final comments before we make real templates to start filling
things out?
Some procedural thoughts about the next steps:
I think the initial way to divvy up the work is by functional subgroup
and start with the function list Tomasz has already created since it
is easier build on his organized work. Other areas may need to have
the groups defined. Many items are the same or similar in a
functional group so the template can be made and duplicated quite
easily and filled out off line. A lot of <related_entry> would be in
the same group and of course the <hierarchy> entries would be the same.
For a problem item (like I just can't figure out a good brief
description for this monster), one whole entry can just be posted on
this list and it can be edited or commented on by others just like how
a problem with any AFL formula is shared.
We could leave functional groups as separate files while things are
initially being filled in by different people. Multiple files with
sequential names could easily be combined by a translator program if
we wanted. We could upload files here. Most of this web
collaborative file stuff is beyond my experience. I am used to just
mounting a remote drive and saving files in my local network.
It seems like we would need to produce some test docs program (HTML?)
soon to test our sections to get feedback and pick out errors quickly.
BR,
Dennis
Proposed list of data items:
<entry>
<entry_name> Glossary entry text (may include multiple words)
<full_name> Expanded entry name
<description> Brief description of the entry, use, or functionality
<return_type> a, n, t, an, nt (data type of the return value for
functions)
<return_name> optional name for the return data
<arg_type> a, n, t, an, nt (data type of the argument value for
functions and procedures --one per argument)
<arg_name> optional argument name
<arg_default> optional argument default value
<link_url> http://www... (optional link to appropriate doc --like a
wikipedia article on CCI definition)
<link_name> descriptive or generic name of link --to click on
(optional for the links below)
<abdoc_link> http://www.amibroker.com/f?functionName (optional link
to appropriate AB doc)
<video_link> http://www.amibroker.net/video/... (optional link to
appropriate AB video)
<tutorial_link> http://www.amibroker.com/guide/... (optional link to
appropriate AB tutorial doc)
<kbdoc_link> http://www.amibroker.com/kb/... (optional link to
appropriate AB knowledge base doc)
<ukbdoc_link> http://www.amibroker.org/userkb/... (optional link to
appropriate user knowledge base doc)
<ab_version> x.x (first AB version to support feature)
<hierarchy> Hierarchy category keyword (additional entries for each
lower level)
<search_tag> Search Terms (one per entry, but can have multiple word
term)
<related_entry> A see also glossary entry of a related item (one per
entry)
</entry>
On Sep 3, 2008, at 5:24 AM, Mike wrote:
> 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 amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@xxx> 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 <sfclimbers@xxx> 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/
|