PCGen Wiki - User contributions [en]

Separator Characters

2009-04-09T00:50:00Z

Michael W. Fender: /* Discussion */

{| align="right"
| __TOC__
|}

==Background==

There is an issue as far as long-term consistency for the use of characters to represent logical "AND" and "OR"

This document uses CHOOSE:TEMPLATE (since it doesn't exist) as an example. For additional CHOOSE tokens and proposals, you can see [[Architecture Changes 5.17]]

To readers: Please add additional options if you have additional ideas. You may find the [[Data LST Standards]] useful to look at reserved characters.

==Option #1, Using Pipe as an OR separator, Using Comma as an AND separator==

===Using Primitives===

CHOOSE:TEMPLATE|Template1|Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo|!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo,!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo|!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar|TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo|!TYPE=Bar]|QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar],QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar|TYPE=Goo]|QUALIFIED,!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

* Note that this is the existing syntax used in the CHOOSE proposals as they are shown on the Wiki. [TRP]
* Showing this syntax to a few non coders it definitely wasn't instinctively clear that ',' was an AND symbol. However, '|' was instinctively picked up as an OR symbol [[User:Karianna|karianna]] 18:59, 1 April 2009 (CEST)
* Part of that is that the pipe '|' just seems to break that attention naturally, which is why it works so well as a subtoken separator. But I think we should move away from giving two jobs to the same thing.--[[User:Michael W. Fender|Fluxxdog]] 01:12, 2 April 2009 (CEST)
Insert comments on option #1 here.

==Option #2, Using Comma as an OR separator, Using Ampersand as an AND separator==

===Using Primitives===

CHOOSE:TEMPLATE|Template1,Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo,!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo&!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar,TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar],QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar]&QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar,TYPE=Goo],QUALIFIED&!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

*I think this is a problem, as ampersand is not a reserved character in PCGen. This is used in actual data that we ship, and thus we would expect homebrews to feel this character is also legal. Therefore, in order to implement this properly, we end up having to have a Data Converter, as this will break existing PCs. (which is the open FREQ, not the item completed for 5.16). While I think this is a nice idea, I think the hurdle is too large to do this quickly. [TRP]

Insert other comments on option #2 here.

==Option #3, Using <OR> as an OR separator, Using <AND> as an AND separator==

===Using Primitives===

CHOOSE:TEMPLATE|Template1<OR>Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo<OR>!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo<AND>!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo<OR>!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar<OR>TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo<OR>!TYPE=Bar]<OR>QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar]<AND>QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar<OR>TYPE=Goo]<OR>QUALIFIED<AND>!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

* Note that the unicode discussion here was broken out into option #4. - thpr Apr 4

*I Have a similar concern here to option #2, as we have not reserved < or > as restricted characters. < and > are used in actual data that we ship, and thus we would expect homebrews to feel this character is also legal. There is less risk of using (literally) <OR> or <AND>, which makes this somewhat safer than option #2. However, this does introduce restrictions on data naming. In order to implement this without risk, we end up having to have a Data Converter, as this will break existing PCs. (which is the open FREQ, not the item completed for 5.16). I think the hurdle is too large to do the FREQ converter quickly. [TRP]

*Do the characters '<' and '>' matter? Are there other characters that can't be used in a key name that can be used for identifying a logical operator? What about '$'? Are there any characters that we cannot use whatsoever for this? --[[User:Michael W. Fender|Fluxxdog]] 04:03, 1 April 2009 (CEST)

:* You may find the [[Data LST Standards]] useful to find reserved characters.
::*Not as helpful as you think. This just lists what should and shouldn't be used in our releases, not what actually can and can't be used.
::::*Not True: Characters which should never be used in object names are Commas (,), Pipes (|), Backslashes (\), Colons (:), Semicolons (;), Periods (.), Brackets ([]), Percent (%), Asterisk (*) and Equals (=). Perhaps we should change the language to "must not be used" to be more RFC 2119-like and avoid confusion. [TRP]
:::For example, we shouldn't use a backslash '\' but we can.
::::*I'm not convinced. Legality isn't defined by what parses cleanly. There are specific reasons each of those characters is prohibited. Try using backslash in a name inside a count() inside a Formula and see if it works. If that does work, I'd have to go code hunting to figure out what the case is that prohibits backslash, but it's on that list for a reason. [TRP]
:::::*...You don't know why? OK< just to test your challenge, I tried making a feat and having something else count() that number of times I took that feat. Problem is, it won't even let me take the feat. Possible safeguard? - Fluxxdog
:::DEFINE:Spaced\Variable|0 BONUS:VAR|Spaced\Variable|3 DESC:Here's the value: %1|Spaced\Variable
:::...still spits out "''Here's the value: 3''"--[[User:Michael W. Fender|Fluxxdog]] 23:35, 4 April 2009 (CEST)
:::I'll double back a bit. If we go the route of using our "shouldn't use" characters, what options do we have?
::::(snip - please read [[Data LST Standards]])
::::* The issue here is that the items prohibited from names are the ONLY characters we can use without writing a converter. [TRP]
:::None of these should be used as they already have other functions already.
::::*This is where the problem lies.
:::::* Depends on your definition of problem, but the point I have is that we either make sacrifices from the ideal, or we delay the conversion to these tokens until we can reach the ideal, which may be years away. I'd rather make sacrifices, which means using the characters on the prohibited list or getting REALLY wide agreement and community input that we can break datasets. [TRP]
::::::*That's my point. Who uses a backslash in their data sets? And the backslash isn't used anywhere else in LST files already. I'd say it's the ideal nominee for such an operation. - Fluxxdog
:::*Backslashes (\)
:::Curious thought, does anything actually use this? I don't think I've seen anything other than file names, which aren't used in LST files.
::::CHOOSE:TEMPLATE|Extra Weaponry\OR\Extra Appendage\OR\Extra Flavor\OR\Candle Power\OR\Super Eyesight
:::Unless a backslash is already being used, that doesn't look too bad itself. And it's highly unlikely, even more so than < and >, that it's used in LST files for even homebrews. It certainly isn't in our LST files now.--[[User:Michael W. Fender|Fluxxdog]] 02:32, 5 April 2009 (CEST)

* [nuance] I think the lower case version stands out better.

:* I'll definitely agree with nuance on using lowercase for 'and' and 'or'. Makes it so much more obvious.--[[User:Michael W. Fender|Fluxxdog]] 01:08, 2 April 2009 (CEST)

::* I happen to prefer the uppercase versions. - thpr 
:::One needs to consider also that these will often be used with Primitive objects, e.g.: 
:::CHOOSE:TEMPLATE|Extra Weaponry<or>Extra Appendage<or>Extra Flavor<or>Candle Power<or>Super Eyesight 
:::CHOOSE:TEMPLATE|Extra Weaponry<OR>Extra Appendage<OR>Extra Flavor<OR>Candle Power<OR>Super Eyesight 
:::... so I feel that the upper case keyword is far more consistent with our tokens (where the keywords like TEMPLATE, TYPE, etc. are all upper case) and also stand out more.
:::*How dare you use logic! ^^ But yeah, when you put it that way, we should stick to the standard of using CAPS for hardcoded words.--[[User:Michael W. Fender|Fluxxdog]] 23:35, 4 April 2009 (CEST)

*Just a tad bit of a summation here: If we use a character to denote the logical operators, the backslash '\' would seem the ideal choice as it's already restricted from being used in key names, so \AND\ and \OR\? Unless I'm misunderstanding you, Tom, out of the "don't use" list, this is the only one that's both
::A) not in use for some other purpose
::B) not in use for data sets
:If I'm wrong, please say so.--[[User:Michael W. Fender|Fluxxdog]] 16:26, 5 April 2009 (CEST)
::* If the path is to follow the spelled-out separators, then of the reserved characters (,|\:.[]%*=), .[]%= are already in the syntax and can't be used due to parsing problems. : is our main token/value separator, and I'd really like to avoid that (though we can use it if necessary). That leaves ,|\* of which only | is used elsewhere in the token (as a separator). ,*\ all remain unused in the context of CHOOSE. , is used elsewhere, but if we convert the other tokens, it would otherwise be unused. [TRP]
:::*Here's what I'm getting at: Backslash is not used anywhere else. I've searched all the LST files in the data sets we publish (and just to be sure, I checked the alpha sets too) and nothing uses it. I don't even recall coming across a token that does use it. I'd rather leave the comma free, just in case and to avoid any confusion, and using a mathematical operator '*' just seems to ask for trouble somewhere.
:::If we go this route, is there any reason not to use the backslash for this? I.E. \AND\ \OR\ --[[User:Michael W. Fender|Fluxxdog]] 01:14, 6 April 2009 (CEST)
::::* From a programming perspective, \AND\ is just as easy as a comma. However, just to be clear, this process is to gather opinions, and we are missing some key players so far. If the backslash is considered unclear, then that will be a major reason for it not to be used, and it will not be used. You seem to have a strong opinion about this, but you need to give other people a chance to express their opinion as well. Just because it is not used elsewhere, doesn't mean it is inevitable under this option. [TRP]
:::::*Heh, not trying to dominate here, but yeah, I think this is the better way. I dislike option 1 and 2 as symbolism in a LST file is pretty aggravating on its own. (I'm pretty familiar with wild cards, so using '%' wasn't a big leap for me.) Using the words AND and OR would make it so much clearer. I dislike option 4 because it would require us to train people how to use such non-standard characters. Option 3 seems to be dependent on which character(s) we use to mark the logical operators, so I'd like to narrow it down to a best choice to get behind.
::::::In the end, I won't be the one to make the final call. But when that call is made, I'll have contributed something to the process, which is why I've joined with the team in the first place.
::::::And the rest of you just watching form the side lines, chime in! Tom's right, 3 people can't haggle about this by themselves! :p --[[User:Michael W. Fender|Fluxxdog]] 02:26, 6 April 2009 (CEST)

* [[User:Nuance|nuance]] Backslashes—I hate this option. It's hard to say how much I hate it.
:*OK, I'll be the crazy one to ask this: Why would this be bad for logical operators? --Fluxxdog

* [[User:Nuance|nuance]] Can I point out I'm also convinced we shouldn't use / or - in things like class names. is CL=Funky-Gibbon asking for how many levels in class "Funky-Gibbon" or is it asking for how many levels in class "Funky" less the variable "Gibbon". If I defined the variable Gibbon would it change the answer, what if I has class Funky and Variable Gibbon already defined and then defined class Funky-Gibbon? Same argument with / what does CL=Funky/Gibbon mean?
:*I know it used to be a rule that we weren't supposed to use dashes '-' for names. It seems that got repealed at some point. I think that's part of the discussion on LST naming standards. (As far the CL= question, this is why I quickly lumped to the classlevel("") function. But that's me ^^)--[[User:Michael W. Fender|Fluxxdog]] 02:42, 9 April 2009 (CEST)

Insert comments on option #3 here.

==Option #4, Leverage Unicode to use other separators, e.g. «OR» as an OR separator, Using «AND» as an AND separator==

Examples use lowercase

===Using Primitives===

CHOOSE:TEMPLATE|Template1«or»Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo«or»!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo«and»!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo«or»!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar«or»TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo«or»!TYPE=Bar]«or»QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar]«and»QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar«or»TYPE=Goo]«or»QUALIFIED«and»!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

* [nuance] LST files are UTF8, so theoretically we can use any unicode character. The problem with that is editor support—which it has to be said is getting better all the time. Since full unicde may be a bit of a shock , iso-8859-1 (latin 1) has « and » (alt0171 and alt0187 respectively). It also has ¿ (alt0191) which ties up nicely with ? if was want to wrap words.

:Of course, fully in the realm of unicode madness, we could always use ∧ for and, and ∨ for or, but the data folk might shoot us :-). Actually we could consider ^ to mean and, paired with |

::CHOOSE:TEMPLATE|PC[TYPE=Foo^!TYPE=Bar|TYPE=Goo]|QUALIFIED^!PC

::...allows a choice of:
::(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
::OR
::(b) Any Template that the PC is qualified to take, but has not yet taken.

:I think I prefer the last one, but I don't like the way | looks against ]. On this wiki ! is hard to distinguish from |, ¬ (shift ` on my keyboard) actually means not. I think using « and » in place of [ and ], and ¬ for not

::CHOOSE:TEMPLATE|PC«TYPE=Foo^¬TYPE=Bar|TYPE=Goo»|QUALIFIED^¬PC

:is easier to read but that might be a bit radical. Perhaps it's time we has that full reserved characters discussion.
:*Very true since we don't seem to have a full list (see above in option 3 about standards vs. actually allowed)--[[User:Michael W. Fender|Fluxxdog]] 23:58, 4 April 2009 (CEST)

*I'd like to move away from symbolism for words and actually use the words themselves. It makes it a lot easier for new people to read.--[[User:Michael W. Fender|Fluxxdog]] 01:08, 2 April 2009 (CEST)

*Using '«' and '»' is a good idea, but how exactly do you type that in? I think we should stick closer to what's available on the common keyboards without having to dig through a font list. Although, that gives me an idea... What about a character combinations?

:* [[User:Nuance|nuance]] Sorry if it was a bit opaque, but I gave instructions for how to type it (on a windows machine at least). Press and hold the "alt" key to the left of your space bar. Now, using the numeric keypad, type the numbers 0171, realease the "alt" key. Et viola «. » is similarly produced with the numbers 0187. Once you have one of them cut and paste is also an option. Since we aren't fully in the unicode realm here, most OSes have some way to type characters in the ios-8859-1 range.
::*I'm not saying it's a bad idea, I'm saying it's not a good idea. People will have to look into some kind of "tips and tricks" for their keyboard AND OS AND language AND font, since not every combination will work like that. Heck, tested it on 3 different programs on my system and it doesn't work at all. I think this is definitely a case of "the simpler the better".--[[User:Michael W. Fender|Fluxxdog]] 23:58, 4 April 2009 (CEST)

::: [http://en.wikipedia.org/wiki/Guillemets#Typing_.22.C2.AB.22_and_.22.C2.BB.22_on_computers| Typing the Guilemets « »]
:::*We'd have to include that link everytime «AND» or «OR» is included or put the information in the docs just to ensure everyone has that info when coding LST files. I'd say, at the very least, let's stick with characters that can't or shouldn't be used in Key names.--[[User:Michael W. Fender|Fluxxdog]] 02:19, 5 April 2009 (CEST)

::::[[User:Nuance|nuance]] I disagree, we would need to include the info in our Docs, but that's it.
::::*It would have to be included for EVERY oppurtunity to use operators.--Fluxxdog
::::[[User:Nuance|nuance]] People already need to read the docs to code in LST. We have mailing lists where people can ask questions. I think « and » are infinitely better than \ in this context. \and\ is horrendously ugly and IMO hard to read. Point is « and » are easy to type on the vast majority of keyboards/OSes. Most poeple who can't figure out how to do something in lst ask or look at the distributed sets. If they're looking at distributed data then—at the very least—they can cut and paste «AND» and «OR» into their own code.

:Hey coders! Could we do something along the lines of <<and>>? Using 2 '<' to signify a logical operator? Surely that must make things easier. -[[User:Michael W. Fender|Fluxxdog]] 01:08, 2 April 2009 (CEST)

:* Really doesn't make a huge difference. The < and > still aren't identified as reserved characters. It reduces the risk slightly, but it's probably small with <AND> and <OR> anyway. - thpr

Insert comments on option #4 here.

Separator Characters

2009-04-09T00:42:50Z

Michael W. Fender: /* Discussion */

{| align="right"
| __TOC__
|}

==Background==

There is an issue as far as long-term consistency for the use of characters to represent logical "AND" and "OR"

This document uses CHOOSE:TEMPLATE (since it doesn't exist) as an example. For additional CHOOSE tokens and proposals, you can see [[Architecture Changes 5.17]]

To readers: Please add additional options if you have additional ideas. You may find the [[Data LST Standards]] useful to look at reserved characters.

==Option #1, Using Pipe as an OR separator, Using Comma as an AND separator==

===Using Primitives===

CHOOSE:TEMPLATE|Template1|Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo|!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo,!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo|!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar|TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo|!TYPE=Bar]|QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar],QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar|TYPE=Goo]|QUALIFIED,!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

* Note that this is the existing syntax used in the CHOOSE proposals as they are shown on the Wiki. [TRP]
* Showing this syntax to a few non coders it definitely wasn't instinctively clear that ',' was an AND symbol. However, '|' was instinctively picked up as an OR symbol [[User:Karianna|karianna]] 18:59, 1 April 2009 (CEST)
* Part of that is that the pipe '|' just seems to break that attention naturally, which is why it works so well as a subtoken separator. But I think we should move away from giving two jobs to the same thing.--[[User:Michael W. Fender|Fluxxdog]] 01:12, 2 April 2009 (CEST)
Insert comments on option #1 here.

==Option #2, Using Comma as an OR separator, Using Ampersand as an AND separator==

===Using Primitives===

CHOOSE:TEMPLATE|Template1,Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo,!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo&!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar,TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar],QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar]&QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar,TYPE=Goo],QUALIFIED&!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

*I think this is a problem, as ampersand is not a reserved character in PCGen. This is used in actual data that we ship, and thus we would expect homebrews to feel this character is also legal. Therefore, in order to implement this properly, we end up having to have a Data Converter, as this will break existing PCs. (which is the open FREQ, not the item completed for 5.16). While I think this is a nice idea, I think the hurdle is too large to do this quickly. [TRP]

Insert other comments on option #2 here.

==Option #3, Using <OR> as an OR separator, Using <AND> as an AND separator==

===Using Primitives===

CHOOSE:TEMPLATE|Template1<OR>Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo<OR>!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo<AND>!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo<OR>!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar<OR>TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo<OR>!TYPE=Bar]<OR>QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar]<AND>QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar<OR>TYPE=Goo]<OR>QUALIFIED<AND>!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

* Note that the unicode discussion here was broken out into option #4. - thpr Apr 4

*I Have a similar concern here to option #2, as we have not reserved < or > as restricted characters. < and > are used in actual data that we ship, and thus we would expect homebrews to feel this character is also legal. There is less risk of using (literally) <OR> or <AND>, which makes this somewhat safer than option #2. However, this does introduce restrictions on data naming. In order to implement this without risk, we end up having to have a Data Converter, as this will break existing PCs. (which is the open FREQ, not the item completed for 5.16). I think the hurdle is too large to do the FREQ converter quickly. [TRP]

*Do the characters '<' and '>' matter? Are there other characters that can't be used in a key name that can be used for identifying a logical operator? What about '$'? Are there any characters that we cannot use whatsoever for this? --[[User:Michael W. Fender|Fluxxdog]] 04:03, 1 April 2009 (CEST)

:* You may find the [[Data LST Standards]] useful to find reserved characters.
::*Not as helpful as you think. This just lists what should and shouldn't be used in our releases, not what actually can and can't be used.
::::*Not True: Characters which should never be used in object names are Commas (,), Pipes (|), Backslashes (\), Colons (:), Semicolons (;), Periods (.), Brackets ([]), Percent (%), Asterisk (*) and Equals (=). Perhaps we should change the language to "must not be used" to be more RFC 2119-like and avoid confusion. [TRP]
:::For example, we shouldn't use a backslash '\' but we can.
::::*I'm not convinced. Legality isn't defined by what parses cleanly. There are specific reasons each of those characters is prohibited. Try using backslash in a name inside a count() inside a Formula and see if it works. If that does work, I'd have to go code hunting to figure out what the case is that prohibits backslash, but it's on that list for a reason. [TRP]
:::::*...You don't know why? OK< just to test your challenge, I tried making a feat and having something else count() that number of times I took that feat. Problem is, it won't even let me take the feat. Possible safeguard? - Fluxxdog
:::DEFINE:Spaced\Variable|0 BONUS:VAR|Spaced\Variable|3 DESC:Here's the value: %1|Spaced\Variable
:::...still spits out "''Here's the value: 3''"--[[User:Michael W. Fender|Fluxxdog]] 23:35, 4 April 2009 (CEST)
:::I'll double back a bit. If we go the route of using our "shouldn't use" characters, what options do we have?
::::(snip - please read [[Data LST Standards]])
::::* The issue here is that the items prohibited from names are the ONLY characters we can use without writing a converter. [TRP]
:::None of these should be used as they already have other functions already.
::::*This is where the problem lies.
:::::* Depends on your definition of problem, but the point I have is that we either make sacrifices from the ideal, or we delay the conversion to these tokens until we can reach the ideal, which may be years away. I'd rather make sacrifices, which means using the characters on the prohibited list or getting REALLY wide agreement and community input that we can break datasets. [TRP]
::::::*That's my point. Who uses a backslash in their data sets? And the backslash isn't used anywhere else in LST files already. I'd say it's the ideal nominee for such an operation. - Fluxxdog
:::*Backslashes (\)
:::Curious thought, does anything actually use this? I don't think I've seen anything other than file names, which aren't used in LST files.
::::CHOOSE:TEMPLATE|Extra Weaponry\OR\Extra Appendage\OR\Extra Flavor\OR\Candle Power\OR\Super Eyesight
:::Unless a backslash is already being used, that doesn't look too bad itself. And it's highly unlikely, even more so than < and >, that it's used in LST files for even homebrews. It certainly isn't in our LST files now.--[[User:Michael W. Fender|Fluxxdog]] 02:32, 5 April 2009 (CEST)

* [nuance] I think the lower case version stands out better.

:* I'll definitely agree with nuance on using lowercase for 'and' and 'or'. Makes it so much more obvious.--[[User:Michael W. Fender|Fluxxdog]] 01:08, 2 April 2009 (CEST)

::* I happen to prefer the uppercase versions. - thpr 
:::One needs to consider also that these will often be used with Primitive objects, e.g.: 
:::CHOOSE:TEMPLATE|Extra Weaponry<or>Extra Appendage<or>Extra Flavor<or>Candle Power<or>Super Eyesight 
:::CHOOSE:TEMPLATE|Extra Weaponry<OR>Extra Appendage<OR>Extra Flavor<OR>Candle Power<OR>Super Eyesight 
:::... so I feel that the upper case keyword is far more consistent with our tokens (where the keywords like TEMPLATE, TYPE, etc. are all upper case) and also stand out more.
:::*How dare you use logic! ^^ But yeah, when you put it that way, we should stick to the standard of using CAPS for hardcoded words.--[[User:Michael W. Fender|Fluxxdog]] 23:35, 4 April 2009 (CEST)

*Just a tad bit of a summation here: If we use a character to denote the logical operators, the backslash '\' would seem the ideal choice as it's already restricted from being used in key names, so \AND\ and \OR\? Unless I'm misunderstanding you, Tom, out of the "don't use" list, this is the only one that's both
::A) not in use for some other purpose
::B) not in use for data sets
:If I'm wrong, please say so.--[[User:Michael W. Fender|Fluxxdog]] 16:26, 5 April 2009 (CEST)
::* If the path is to follow the spelled-out separators, then of the reserved characters (,|\:.[]%*=), .[]%= are already in the syntax and can't be used due to parsing problems. : is our main token/value separator, and I'd really like to avoid that (though we can use it if necessary). That leaves ,|\* of which only | is used elsewhere in the token (as a separator). ,*\ all remain unused in the context of CHOOSE. , is used elsewhere, but if we convert the other tokens, it would otherwise be unused. [TRP]
:::*Here's what I'm getting at: Backslash is not used anywhere else. I've searched all the LST files in the data sets we publish (and just to be sure, I checked the alpha sets too) and nothing uses it. I don't even recall coming across a token that does use it. I'd rather leave the comma free, just in case and to avoid any confusion, and using a mathematical operator '*' just seems to ask for trouble somewhere.
:::If we go this route, is there any reason not to use the backslash for this? I.E. \AND\ \OR\ --[[User:Michael W. Fender|Fluxxdog]] 01:14, 6 April 2009 (CEST)
::::* From a programming perspective, \AND\ is just as easy as a comma. However, just to be clear, this process is to gather opinions, and we are missing some key players so far. If the backslash is considered unclear, then that will be a major reason for it not to be used, and it will not be used. You seem to have a strong opinion about this, but you need to give other people a chance to express their opinion as well. Just because it is not used elsewhere, doesn't mean it is inevitable under this option. [TRP]
:::::*Heh, not trying to dominate here, but yeah, I think this is the better way. I dislike option 1 and 2 as symbolism in a LST file is pretty aggravating on its own. (I'm pretty familiar with wild cards, so using '%' wasn't a big leap for me.) Using the words AND and OR would make it so much clearer. I dislike option 4 because it would require us to train people how to use such non-standard characters. Option 3 seems to be dependent on which character(s) we use to mark the logical operators, so I'd like to narrow it down to a best choice to get behind.
::::::In the end, I won't be the one to make the final call. But when that call is made, I'll have contributed something to the process, which is why I've joined with the team in the first place.
::::::And the rest of you just watching form the side lines, chime in! Tom's right, 3 people can't haggle about this by themselves! :p --[[User:Michael W. Fender|Fluxxdog]] 02:26, 6 April 2009 (CEST)

* [[User:Nuance|nuance]] Backslashes—I hate this option. It's hard to say how much I hate it.
:*OK, I'll be the crazy one to ask this: Why would this be bad for logical operators? --Fluxxdog

* [[User:Nuance|nuance]] Can I point out I'm also convinced we shouldn't use / or - in things like class names. is CL=Funky-Gibbon asking for how many levels in class "Funky-Gibbon" or is it asking for how many levels in class "Funky" less the variable "Gibbon". If I defined the variable Gibbon would it change the answer, what if I has class Funky and Variable Gibbon already defined and then defined class Funky-Gibbon? Same argument with / what does CL=Funky/Gibbon mean?
:*I know it used to be a rule that we weren't supposed to use dashes '-' for names. It seems that got repealed at some point. I think that's part of the discussion on LST naming standards. (As far the CL= question, this is why I quickly lumped to the classlevel("") function. But that's me ^^)--[[User:Michael W. Fender|Fluxxdog]] 02:42, 9 April 2009 (CEST)

Insert comments on option #3 here.

==Option #4, Leverage Unicode to use other separators, e.g. «OR» as an OR separator, Using «AND» as an AND separator==

Examples use lowercase

===Using Primitives===

CHOOSE:TEMPLATE|Template1«or»Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo«or»!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo«and»!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo«or»!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar«or»TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo«or»!TYPE=Bar]«or»QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar]«and»QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar«or»TYPE=Goo]«or»QUALIFIED«and»!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

* [nuance] LST files are UTF8, so theoretically we can use any unicode character. The problem with that is editor support—which it has to be said is getting better all the time. Since full unicde may be a bit of a shock , iso-8859-1 (latin 1) has « and » (alt0171 and alt0187 respectively). It also has ¿ (alt0191) which ties up nicely with ? if was want to wrap words.

:Of course, fully in the realm of unicode madness, we could always use ∧ for and, and ∨ for or, but the data folk might shoot us :-). Actually we could consider ^ to mean and, paired with |

::CHOOSE:TEMPLATE|PC[TYPE=Foo^!TYPE=Bar|TYPE=Goo]|QUALIFIED^!PC

::...allows a choice of:
::(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
::OR
::(b) Any Template that the PC is qualified to take, but has not yet taken.

:I think I prefer the last one, but I don't like the way | looks against ]. On this wiki ! is hard to distinguish from |, ¬ (shift ` on my keyboard) actually means not. I think using « and » in place of [ and ], and ¬ for not

::CHOOSE:TEMPLATE|PC«TYPE=Foo^¬TYPE=Bar|TYPE=Goo»|QUALIFIED^¬PC

:is easier to read but that might be a bit radical. Perhaps it's time we has that full reserved characters discussion.
:*Very true since we don't seem to have a full list (see above in option 3 about standards vs. actually allowed)--[[User:Michael W. Fender|Fluxxdog]] 23:58, 4 April 2009 (CEST)

*I'd like to move away from symbolism for words and actually use the words themselves. It makes it a lot easier for new people to read.--[[User:Michael W. Fender|Fluxxdog]] 01:08, 2 April 2009 (CEST)

*Using '«' and '»' is a good idea, but how exactly do you type that in? I think we should stick closer to what's available on the common keyboards without having to dig through a font list. Although, that gives me an idea... What about a character combinations?

:* [[User:Nuance|nuance]] Sorry if it was a bit opaque, but I gave instructions for how to type it (on a windows machine at least). Press and hold the "alt" key to the left of your space bar. Now, using the numeric keypad, type the numbers 0171, realease the "alt" key. Et viola «. » is similarly produced with the numbers 0187. Once you have one of them cut and paste is also an option. Since we aren't fully in the unicode realm here, most OSes have some way to type characters in the ios-8859-1 range.
::*I'm not saying it's a bad idea, I'm saying it's not a good idea. People will have to look into some kind of "tips and tricks" for their keyboard AND OS AND language AND font, since not every combination will work like that. Heck, tested it on 3 different programs on my system and it doesn't work at all. I think this is definitely a case of "the simpler the better".--[[User:Michael W. Fender|Fluxxdog]] 23:58, 4 April 2009 (CEST)

::: [http://en.wikipedia.org/wiki/Guillemets#Typing_.22.C2.AB.22_and_.22.C2.BB.22_on_computers| Typing the Guilemets « »]
:::*We'd have to include that link everytime «AND» or «OR» is included or put the information in the docs just to ensure everyone has that info when coding LST files. I'd say, at the very least, let's stick with characters that can't or shouldn't be used in Key names.--[[User:Michael W. Fender|Fluxxdog]] 02:19, 5 April 2009 (CEST)

::::[[User:Nuance|nuance]] I disagree, we would need to include the info in our Docs, but that's it. People already need to read the docs to code in LST. We have mailing lists where people can ask questions. I think « and » are infinitely better than \ in this context. \and\ is horrendously ugly and IMO hard to read. Point is « and » are easy to type on the vast majority of keyboards/OSes. Most poeple who can't figure out how to do something in lst ask or look at the distributed sets. If they're looking at distributed data then—at the very least—they can cut and paste «AND» and «OR» into their own code.

:Hey coders! Could we do something along the lines of <<and>>? Using 2 '<' to signify a logical operator? Surely that must make things easier. -[[User:Michael W. Fender|Fluxxdog]] 01:08, 2 April 2009 (CEST)

:* Really doesn't make a huge difference. The < and > still aren't identified as reserved characters. It reduces the risk slightly, but it's probably small with <AND> and <OR> anyway. - thpr

Insert comments on option #4 here.

Separator Characters

2009-04-06T00:26:14Z

Michael W. Fender: /* Discussion */

{| align="right"
| __TOC__
|}

==Background==

There is an issue as far as long-term consistency for the use of characters to represent logical "AND" and "OR"

This document uses CHOOSE:TEMPLATE (since it doesn't exist) as an example. For additional CHOOSE tokens and proposals, you can see [[Architecture Changes 5.17]]

To readers: Please add additional options if you have additional ideas. You may find the [[Data LST Standards]] useful to look at reserved characters.

==Option #1, Using Pipe as an OR separator, Using Comma as an AND separator==

===Using Primitives===

CHOOSE:TEMPLATE|Template1|Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo|!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo,!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo|!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar|TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo|!TYPE=Bar]|QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar],QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar|TYPE=Goo]|QUALIFIED,!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

* Note that this is the existing syntax used in the CHOOSE proposals as they are shown on the Wiki. [TRP]
* Showing this syntax to a few non coders it definitely wasn't instinctively clear that ',' was an AND symbol. However, '|' was instinctively picked up as an OR symbol [[User:Karianna|karianna]] 18:59, 1 April 2009 (CEST)
* Part of that is that the pipe '|' just seems to break that attention naturally, which is why it works so well as a subtoken separator. But I think we should move away from giving two jobs to the same thing.--[[User:Michael W. Fender|Fluxxdog]] 01:12, 2 April 2009 (CEST)
Insert comments on option #1 here.

==Option #2, Using Comma as an OR separator, Using Ampersand as an AND separator==

===Using Primitives===

CHOOSE:TEMPLATE|Template1,Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo,!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo&!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar,TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar],QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar]&QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar,TYPE=Goo],QUALIFIED&!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

*I think this is a problem, as ampersand is not a reserved character in PCGen. This is used in actual data that we ship, and thus we would expect homebrews to feel this character is also legal. Therefore, in order to implement this properly, we end up having to have a Data Converter, as this will break existing PCs. (which is the open FREQ, not the item completed for 5.16). While I think this is a nice idea, I think the hurdle is too large to do this quickly. [TRP]

Insert other comments on option #2 here.

==Option #3, Using <OR> as an OR separator, Using <AND> as an AND separator==

===Using Primitives===

CHOOSE:TEMPLATE|Template1<OR>Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo<OR>!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo<AND>!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo<OR>!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar<OR>TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo<OR>!TYPE=Bar]<OR>QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar]<AND>QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar<OR>TYPE=Goo]<OR>QUALIFIED<AND>!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

* Note that the unicode discussion here was broken out into option #4. - thpr Apr 4

*I Have a similar concern here to option #2, as we have not reserved < or > as restricted characters. < and > are used in actual data that we ship, and thus we would expect homebrews to feel this character is also legal. There is less risk of using (literally) <OR> or <AND>, which makes this somewhat safer than option #2. However, this does introduce restrictions on data naming. In order to implement this without risk, we end up having to have a Data Converter, as this will break existing PCs. (which is the open FREQ, not the item completed for 5.16). I think the hurdle is too large to do the FREQ converter quickly. [TRP]

*Do the characters '<' and '>' matter? Are there other characters that can't be used in a key name that can be used for identifying a logical operator? What about '$'? Are there any characters that we cannot use whatsoever for this? --[[User:Michael W. Fender|Fluxxdog]] 04:03, 1 April 2009 (CEST)

:* You may find the [[Data LST Standards]] useful to find reserved characters.
::*Not as helpful as you think. This just lists what should and shouldn't be used in our releases, not what actually can and can't be used.
::::*Not True: Characters which should never be used in object names are Commas (,), Pipes (|), Backslashes (\), Colons (:), Semicolons (;), Periods (.), Brackets ([]), Percent (%), Asterisk (*) and Equals (=). Perhaps we should change the language to "must not be used" to be more RFC 2119-like and avoid confusion. [TRP]
:::For example, we shouldn't use a backslash '\' but we can.
::::*I'm not convinced. Legality isn't defined by what parses cleanly. There are specific reasons each of those characters is prohibited. Try using backslash in a name inside a count() inside a Formula and see if it works. If that does work, I'd have to go code hunting to figure out what the case is that prohibits backslash, but it's on that list for a reason. [TRP]
:::::*...You don't know why? OK< just to test your challenge, I tried making a feat and having something else count() that number of times I took that feat. Problem is, it won't even let me take the feat. Possible safeguard? - Fluxxdog
:::DEFINE:Spaced\Variable|0 BONUS:VAR|Spaced\Variable|3 DESC:Here's the value: %1|Spaced\Variable
:::...still spits out "''Here's the value: 3''"--[[User:Michael W. Fender|Fluxxdog]] 23:35, 4 April 2009 (CEST)
:::I'll double back a bit. If we go the route of using our "shouldn't use" characters, what options do we have?
::::(snip - please read [[Data LST Standards]])
::::* The issue here is that the items prohibited from names are the ONLY characters we can use without writing a converter. [TRP]
:::None of these should be used as they already have other functions already.
::::*This is where the problem lies.
:::::* Depends on your definition of problem, but the point I have is that we either make sacrifices from the ideal, or we delay the conversion to these tokens until we can reach the ideal, which may be years away. I'd rather make sacrifices, which means using the characters on the prohibited list or getting REALLY wide agreement and community input that we can break datasets. [TRP]
::::::*That's my point. Who uses a backslash in their data sets? And the backslash isn't used anywhere else in LST files already. I'd say it's the ideal nominee for such an operation. - Fluxxdog
:::*Backslashes (\)
:::Curious thought, does anything actually use this? I don't think I've seen anything other than file names, which aren't used in LST files.
::::CHOOSE:TEMPLATE|Extra Weaponry\OR\Extra Appendage\OR\Extra Flavor\OR\Candle Power\OR\Super Eyesight
:::Unless a backslash is already being used, that doesn't look too bad itself. And it's highly unlikely, even more so than < and >, that it's used in LST files for even homebrews. It certainly isn't in our LST files now.--[[User:Michael W. Fender|Fluxxdog]] 02:32, 5 April 2009 (CEST)

* [nuance] I think the lower case version stands out better.

:* I'll definitely agree with nuance on using lowercase for 'and' and 'or'. Makes it so much more obvious.--[[User:Michael W. Fender|Fluxxdog]] 01:08, 2 April 2009 (CEST)

::* I happen to prefer the uppercase versions. - thpr 
:::One needs to consider also that these will often be used with Primitive objects, e.g.: 
:::CHOOSE:TEMPLATE|Extra Weaponry<or>Extra Appendage<or>Extra Flavor<or>Candle Power<or>Super Eyesight 
:::CHOOSE:TEMPLATE|Extra Weaponry<OR>Extra Appendage<OR>Extra Flavor<OR>Candle Power<OR>Super Eyesight 
:::... so I feel that the upper case keyword is far more consistent with our tokens (where the keywords like TEMPLATE, TYPE, etc. are all upper case) and also stand out more.
:::*How dare you use logic! ^^ But yeah, when you put it that way, we should stick to the standard of using CAPS for hardcoded words.--[[User:Michael W. Fender|Fluxxdog]] 23:35, 4 April 2009 (CEST)

*Just a tad bit of a summation here: If we use a character to denote the logical operators, the backslash '\' would seem the ideal choice as it's already restricted from being used in key names, so \AND\ and \OR\? Unless I'm misunderstanding you, Tom, out of the "don't use" list, this is the only one that's both
::A) not in use for some other purpose
::B) not in use for data sets
:If I'm wrong, please say so.--[[User:Michael W. Fender|Fluxxdog]] 16:26, 5 April 2009 (CEST)
::* If the path is to follow the spelled-out separators, then of the reserved characters (,|\:.[]%*=), .[]%= are already in the syntax and can't be used due to parsing problems. : is our main token/value separator, and I'd really like to avoid that (though we can use it if necessary). That leaves ,|\* of which only | is used elsewhere in the token (as a separator). ,*\ all remain unused in the context of CHOOSE. , is used elsewhere, but if we convert the other tokens, it would otherwise be unused. [TRP]
:::*Here's what I'm getting at: Backslash is not used anywhere else. I've searched all the LST files in the data sets we publish (and just to be sure, I checked the alpha sets too) and nothing uses it. I don't even recall coming across a token that does use it. I'd rather leave the comma free, just in case and to avoid any confusion, and using a mathematical operator '*' just seems to ask for trouble somewhere.
:::If we go this route, is there any reason not to use the backslash for this? I.E. \AND\ \OR\ --[[User:Michael W. Fender|Fluxxdog]] 01:14, 6 April 2009 (CEST)
::::* From a programming perspective, \AND\ is just as easy as a comma. However, just to be clear, this process is to gather opinions, and we are missing some key players so far. If the backslash is considered unclear, then that will be a major reason for it not to be used, and it will not be used. You seem to have a strong opinion about this, but you need to give other people a chance to express their opinion as well. Just because it is not used elsewhere, doesn't mean it is inevitable under this option. [TRP]
:::::*Heh, not trying to dominate here, but yeah, I think this is the better way. I dislike option 1 and 2 as symbolism in a LST file is pretty aggravating on its own. (I'm pretty familiar with wild cards, so using '%' wasn't a big leap for me.) Using the words AND and OR would make it so much clearer. I dislike option 4 because it would require us to train people how to use such non-standard characters. Option 3 seems to be dependent on which character(s) we use to mark the logical operators, so I'd like to narrow it down to a best choice to get behind.
::::::In the end, I won't be the one to make the final call. But when that call is made, I'll have contributed something to the process, which is why I've joined with the team in the first place.
::::::And the rest of you just watching form the side lines, chime in! Tom's right, 3 people can't haggle about this by themselves! :p --[[User:Michael W. Fender|Fluxxdog]] 02:26, 6 April 2009 (CEST)
Insert comments on option #3 here.

==Option #4, Leverage Unicode to use other separators, e.g. «OR» as an OR separator, Using «AND» as an AND separator==

Examples use lowercase

===Using Primitives===

CHOOSE:TEMPLATE|Template1«or»Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo«or»!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo«and»!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo«or»!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar«or»TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo«or»!TYPE=Bar]«or»QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar]«and»QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar«or»TYPE=Goo]«or»QUALIFIED«and»!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

* [nuance] LST files are UTF8, so theoretically we can use any unicode character. The problem with that is editor support—which it has to be said is getting better all the time. Since full unicde may be a bit of a shock , iso-8859-1 (latin 1) has « and » (alt0171 and alt0187 respectively). It also has ¿ (alt0191) which ties up nicely with ? if was want to wrap words.

:Of course, fully in the realm of unicode madness, we could always use ∧ for and, and ∨ for or, but the data folk might shoot us :-). Actually we could consider ^ to mean and, paired with |

::CHOOSE:TEMPLATE|PC[TYPE=Foo^!TYPE=Bar|TYPE=Goo]|QUALIFIED^!PC

::...allows a choice of:
::(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
::OR
::(b) Any Template that the PC is qualified to take, but has not yet taken.

:I think I prefer the last one, but I don't like the way | looks against ]. On this wiki ! is hard to distinguish from |, ¬ (shift ` on my keyboard) actually means not. I think using « and » in place of [ and ], and ¬ for not

::CHOOSE:TEMPLATE|PC«TYPE=Foo^¬TYPE=Bar|TYPE=Goo»|QUALIFIED^¬PC

:is easier to read but that might be a bit radical. Perhaps it's time we has that full reserved characters discussion.
:*Very true since we don't seem to have a full list (see above in option 3 about standards vs. actually allowed)--[[User:Michael W. Fender|Fluxxdog]] 23:58, 4 April 2009 (CEST)

*I'd like to move away from symbolism for words and actually use the words themselves. It makes it a lot easier for new people to read.--[[User:Michael W. Fender|Fluxxdog]] 01:08, 2 April 2009 (CEST)

*Using '«' and '»' is a good idea, but how exactly do you type that in? I think we should stick closer to what's available on the common keyboards without having to dig through a font list. Although, that gives me an idea... What about a character combinations?

:* [[User:Nuance|nuance]] Sorry if it was a bit opaque, but I gave instructions for how to type it (on a windows machine at least). Press and hold the "alt" key to the left of your space bar. Now, using the numeric keypad, type the numbers 0171, realease the "alt" key. Et viola «. » is similarly produced with the numbers 0187. Once you have one of them cut and paste is also an option. Since we aren't fully in the unicode realm here, most OSes have some way to type characters in the ios-8859-1 range.
::*I'm not saying it's a bad idea, I'm saying it's not a good idea. People will have to look into some kind of "tips and tricks" for their keyboard AND OS AND language AND font, since not every combination will work like that. Heck, tested it on 3 different programs on my system and it doesn't work at all. I think this is definitely a case of "the simpler the better".--[[User:Michael W. Fender|Fluxxdog]] 23:58, 4 April 2009 (CEST)

::: [http://en.wikipedia.org/wiki/Guillemets#Typing_.22.C2.AB.22_and_.22.C2.BB.22_on_computers| Typing the Guilemets « »]
:::*We'd have to include that link everytime «AND» or «OR» is included or put the information in the docs just to ensure everyone has that info when coding LST files. I'd say, at the very least, let's stick with characters that can't or shouldn't be used in Key names.--[[User:Michael W. Fender|Fluxxdog]] 02:19, 5 April 2009 (CEST)

:Hey coders! Could we do something along the lines of <<and>>? Using 2 '<' to signify a logical operator? Surely that must make things easier. -[[User:Michael W. Fender|Fluxxdog]] 01:08, 2 April 2009 (CEST)

:* Really doesn't make a huge difference. The < and > still aren't identified as reserved characters. It reduces the risk slightly, but it's probably small with <AND> and <OR> anyway. - thpr

Insert comments on option #4 here.

Separator Characters

2009-04-05T23:14:00Z

Michael W. Fender: /* Discussion */

{| align="right"
| __TOC__
|}

==Background==

There is an issue as far as long-term consistency for the use of characters to represent logical "AND" and "OR"

This document uses CHOOSE:TEMPLATE (since it doesn't exist) as an example. For additional CHOOSE tokens and proposals, you can see [[Architecture Changes 5.17]]

To readers: Please add additional options if you have additional ideas. You may find the [[Data LST Standards]] useful to look at reserved characters.

==Option #1, Using Pipe as an OR separator, Using Comma as an AND separator==

===Using Primitives===

CHOOSE:TEMPLATE|Template1|Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo|!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo,!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo|!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar|TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo|!TYPE=Bar]|QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar],QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar|TYPE=Goo]|QUALIFIED,!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

* Note that this is the existing syntax used in the CHOOSE proposals as they are shown on the Wiki. [TRP]
* Showing this syntax to a few non coders it definitely wasn't instinctively clear that ',' was an AND symbol. However, '|' was instinctively picked up as an OR symbol [[User:Karianna|karianna]] 18:59, 1 April 2009 (CEST)
* Part of that is that the pipe '|' just seems to break that attention naturally, which is why it works so well as a subtoken separator. But I think we should move away from giving two jobs to the same thing.--[[User:Michael W. Fender|Fluxxdog]] 01:12, 2 April 2009 (CEST)
Insert comments on option #1 here.

==Option #2, Using Comma as an OR separator, Using Ampersand as an AND separator==

===Using Primitives===

CHOOSE:TEMPLATE|Template1,Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo,!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo&!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar,TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar],QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar]&QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar,TYPE=Goo],QUALIFIED&!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

*I think this is a problem, as ampersand is not a reserved character in PCGen. This is used in actual data that we ship, and thus we would expect homebrews to feel this character is also legal. Therefore, in order to implement this properly, we end up having to have a Data Converter, as this will break existing PCs. (which is the open FREQ, not the item completed for 5.16). While I think this is a nice idea, I think the hurdle is too large to do this quickly. [TRP]

Insert other comments on option #2 here.

==Option #3, Using <OR> as an OR separator, Using <AND> as an AND separator==

===Using Primitives===

CHOOSE:TEMPLATE|Template1<OR>Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo<OR>!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo<AND>!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo<OR>!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar<OR>TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo<OR>!TYPE=Bar]<OR>QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar]<AND>QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar<OR>TYPE=Goo]<OR>QUALIFIED<AND>!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

* Note that the unicode discussion here was broken out into option #4. - thpr Apr 4

*I Have a similar concern here to option #2, as we have not reserved < or > as restricted characters. < and > are used in actual data that we ship, and thus we would expect homebrews to feel this character is also legal. There is less risk of using (literally) <OR> or <AND>, which makes this somewhat safer than option #2. However, this does introduce restrictions on data naming. In order to implement this without risk, we end up having to have a Data Converter, as this will break existing PCs. (which is the open FREQ, not the item completed for 5.16). I think the hurdle is too large to do the FREQ converter quickly. [TRP]

*Do the characters '<' and '>' matter? Are there other characters that can't be used in a key name that can be used for identifying a logical operator? What about '$'? Are there any characters that we cannot use whatsoever for this? --[[User:Michael W. Fender|Fluxxdog]] 04:03, 1 April 2009 (CEST)

:* You may find the [[Data LST Standards]] useful to find reserved characters.
::*Not as helpful as you think. This just lists what should and shouldn't be used in our releases, not what actually can and can't be used.
::::*Not True: Characters which should never be used in object names are Commas (,), Pipes (|), Backslashes (\), Colons (:), Semicolons (;), Periods (.), Brackets ([]), Percent (%), Asterisk (*) and Equals (=). Perhaps we should change the language to "must not be used" to be more RFC 2119-like and avoid confusion. [TRP]
:::For example, we shouldn't use a backslash '\' but we can.
::::*I'm not convinced. Legality isn't defined by what parses cleanly. There are specific reasons each of those characters is prohibited. Try using backslash in a name inside a count() inside a Formula and see if it works. If that does work, I'd have to go code hunting to figure out what the case is that prohibits backslash, but it's on that list for a reason. [TRP]
:::::*...You don't know why? OK< just to test your challenge, I tried making a feat and having something else count() that number of times I took that feat. Problem is, it won't even let me take the feat. Possible safeguard? - Fluxxdog
:::DEFINE:Spaced\Variable|0 BONUS:VAR|Spaced\Variable|3 DESC:Here's the value: %1|Spaced\Variable
:::...still spits out "''Here's the value: 3''"--[[User:Michael W. Fender|Fluxxdog]] 23:35, 4 April 2009 (CEST)
:::I'll double back a bit. If we go the route of using our "shouldn't use" characters, what options do we have?
::::(snip - please read [[Data LST Standards]])
::::* The issue here is that the items prohibited from names are the ONLY characters we can use without writing a converter. [TRP]
:::None of these should be used as they already have other functions already.
::::*This is where the problem lies.
:::::* Depends on your definition of problem, but the point I have is that we either make sacrifices from the ideal, or we delay the conversion to these tokens until we can reach the ideal, which may be years away. I'd rather make sacrifices, which means using the characters on the prohibited list or getting REALLY wide agreement and community input that we can break datasets. [TRP]
::::::*That's my point. Who uses a backslash in their data sets? And the backslash isn't used anywhere else in LST files already. I'd say it's the ideal nominee for such an operation. - Fluxxdog
:::*Backslashes (\)
:::Curious thought, does anything actually use this? I don't think I've seen anything other than file names, which aren't used in LST files.
::::CHOOSE:TEMPLATE|Extra Weaponry\OR\Extra Appendage\OR\Extra Flavor\OR\Candle Power\OR\Super Eyesight
:::Unless a backslash is already being used, that doesn't look too bad itself. And it's highly unlikely, even more so than < and >, that it's used in LST files for even homebrews. It certainly isn't in our LST files now.--[[User:Michael W. Fender|Fluxxdog]] 02:32, 5 April 2009 (CEST)

* [nuance] I think the lower case version stands out better.

:* I'll definitely agree with nuance on using lowercase for 'and' and 'or'. Makes it so much more obvious.--[[User:Michael W. Fender|Fluxxdog]] 01:08, 2 April 2009 (CEST)

::* I happen to prefer the uppercase versions. - thpr 
:::One needs to consider also that these will often be used with Primitive objects, e.g.: 
:::CHOOSE:TEMPLATE|Extra Weaponry<or>Extra Appendage<or>Extra Flavor<or>Candle Power<or>Super Eyesight 
:::CHOOSE:TEMPLATE|Extra Weaponry<OR>Extra Appendage<OR>Extra Flavor<OR>Candle Power<OR>Super Eyesight 
:::... so I feel that the upper case keyword is far more consistent with our tokens (where the keywords like TEMPLATE, TYPE, etc. are all upper case) and also stand out more.
:::*How dare you use logic! ^^ But yeah, when you put it that way, we should stick to the standard of using CAPS for hardcoded words.--[[User:Michael W. Fender|Fluxxdog]] 23:35, 4 April 2009 (CEST)

*Just a tad bit of a summation here: If we use a character to denote the logical operators, the backslash '\' would seem the ideal choice as it's already restricted from being used in key names, so \AND\ and \OR\? Unless I'm misunderstanding you, Tom, out of the "don't use" list, this is the only one that's both
::A) not in use for some other purpose
::B) not in use for data sets
:If I'm wrong, please say so.--[[User:Michael W. Fender|Fluxxdog]] 16:26, 5 April 2009 (CEST)
::* If the path is to follow the spelled-out separators, then of the reserved characters (,|\:.[]%*=), .[]%= are already in the syntax and can't be used due to parsing problems. : is our main token/value separator, and I'd really like to avoid that (though we can use it if necessary). That leaves ,|\* of which only | is used elsewhere in the token (as a separator). ,*\ all remain unused in the context of CHOOSE. , is used elsewhere, but if we convert the other tokens, it would otherwise be unused. [TRP]
:::*Here's what I'm getting at: Backslash is not used anywhere else. I've searched all the LST files in the data sets we publish (and just to be sure, I checked the alpha sets too) and nothing uses it. I don't even recall coming across a token that does use it. I'd rather leave the comma free, just in case and to avoid any confusion, and using a mathematical operator '*' just seems to ask for trouble somewhere.
:::If we go this route, is there any reason not to use the backslash for this? I.E. \AND\ \OR\ --[[User:Michael W. Fender|Fluxxdog]] 01:14, 6 April 2009 (CEST)
Insert comments on option #3 here.

==Option #4, Leverage Unicode to use other separators, e.g. «OR» as an OR separator, Using «AND» as an AND separator==

Examples use lowercase

===Using Primitives===

CHOOSE:TEMPLATE|Template1«or»Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo«or»!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo«and»!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo«or»!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar«or»TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo«or»!TYPE=Bar]«or»QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar]«and»QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar«or»TYPE=Goo]«or»QUALIFIED«and»!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

* [nuance] LST files are UTF8, so theoretically we can use any unicode character. The problem with that is editor support—which it has to be said is getting better all the time. Since full unicde may be a bit of a shock , iso-8859-1 (latin 1) has « and » (alt0171 and alt0187 respectively). It also has ¿ (alt0191) which ties up nicely with ? if was want to wrap words.

:Of course, fully in the realm of unicode madness, we could always use ∧ for and, and ∨ for or, but the data folk might shoot us :-). Actually we could consider ^ to mean and, paired with |

::CHOOSE:TEMPLATE|PC[TYPE=Foo^!TYPE=Bar|TYPE=Goo]|QUALIFIED^!PC

::...allows a choice of:
::(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
::OR
::(b) Any Template that the PC is qualified to take, but has not yet taken.

:I think I prefer the last one, but I don't like the way | looks against ]. On this wiki ! is hard to distinguish from |, ¬ (shift ` on my keyboard) actually means not. I think using « and » in place of [ and ], and ¬ for not

::CHOOSE:TEMPLATE|PC«TYPE=Foo^¬TYPE=Bar|TYPE=Goo»|QUALIFIED^¬PC

:is easier to read but that might be a bit radical. Perhaps it's time we has that full reserved characters discussion.
:*Very true since we don't seem to have a full list (see above in option 3 about standards vs. actually allowed)--[[User:Michael W. Fender|Fluxxdog]] 23:58, 4 April 2009 (CEST)

*I'd like to move away from symbolism for words and actually use the words themselves. It makes it a lot easier for new people to read.--[[User:Michael W. Fender|Fluxxdog]] 01:08, 2 April 2009 (CEST)

*Using '«' and '»' is a good idea, but how exactly do you type that in? I think we should stick closer to what's available on the common keyboards without having to dig through a font list. Although, that gives me an idea... What about a character combinations?

:* [[User:Nuance|nuance]] Sorry if it was a bit opaque, but I gave instructions for how to type it (on a windows machine at least). Press and hold the "alt" key to the left of your space bar. Now, using the numeric keypad, type the numbers 0171, realease the "alt" key. Et viola «. » is similarly produced with the numbers 0187. Once you have one of them cut and paste is also an option. Since we aren't fully in the unicode realm here, most OSes have some way to type characters in the ios-8859-1 range.
::*I'm not saying it's a bad idea, I'm saying it's not a good idea. People will have to look into some kind of "tips and tricks" for their keyboard AND OS AND language AND font, since not every combination will work like that. Heck, tested it on 3 different programs on my system and it doesn't work at all. I think this is definitely a case of "the simpler the better".--[[User:Michael W. Fender|Fluxxdog]] 23:58, 4 April 2009 (CEST)

::: [http://en.wikipedia.org/wiki/Guillemets#Typing_.22.C2.AB.22_and_.22.C2.BB.22_on_computers| Typing the Guilemets « »]
:::*We'd have to include that link everytime «AND» or «OR» is included or put the information in the docs just to ensure everyone has that info when coding LST files. I'd say, at the very least, let's stick with characters that can't or shouldn't be used in Key names.--[[User:Michael W. Fender|Fluxxdog]] 02:19, 5 April 2009 (CEST)

:Hey coders! Could we do something along the lines of <<and>>? Using 2 '<' to signify a logical operator? Surely that must make things easier. -[[User:Michael W. Fender|Fluxxdog]] 01:08, 2 April 2009 (CEST)

:* Really doesn't make a huge difference. The < and > still aren't identified as reserved characters. It reduces the risk slightly, but it's probably small with <AND> and <OR> anyway. - thpr

Insert comments on option #4 here.

Separator Characters

2009-04-05T14:26:04Z

Michael W. Fender: /* Discussion */

{| align="right"
| __TOC__
|}

==Background==

There is an issue as far as long-term consistency for the use of characters to represent logical "AND" and "OR"

This document uses CHOOSE:TEMPLATE (since it doesn't exist) as an example. For additional CHOOSE tokens and proposals, you can see [[Architecture Changes 5.17]]

To readers: Please add additional options if you have additional ideas. You may find the [[Data LST Standards]] useful to look at reserved characters.

==Option #1, Using Pipe as an OR separator, Using Comma as an AND separator==

===Using Primitives===

CHOOSE:TEMPLATE|Template1|Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo|!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo,!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo|!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar|TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo|!TYPE=Bar]|QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar],QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar|TYPE=Goo]|QUALIFIED,!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

* Note that this is the existing syntax used in the CHOOSE proposals as they are shown on the Wiki. [TRP]
* Showing this syntax to a few non coders it definitely wasn't instinctively clear that ',' was an AND symbol. However, '|' was instinctively picked up as an OR symbol [[User:Karianna|karianna]] 18:59, 1 April 2009 (CEST)
* Part of that is that the pipe '|' just seems to break that attention naturally, which is why it works so well as a subtoken separator. But I think we should move away from giving two jobs to the same thing.--[[User:Michael W. Fender|Fluxxdog]] 01:12, 2 April 2009 (CEST)
Insert comments on option #1 here.

==Option #2, Using Comma as an OR separator, Using Ampersand as an AND separator==

===Using Primitives===

CHOOSE:TEMPLATE|Template1,Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo,!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo&!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar,TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar],QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar]&QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar,TYPE=Goo],QUALIFIED&!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

*I think this is a problem, as ampersand is not a reserved character in PCGen. This is used in actual data that we ship, and thus we would expect homebrews to feel this character is also legal. Therefore, in order to implement this properly, we end up having to have a Data Converter, as this will break existing PCs. (which is the open FREQ, not the item completed for 5.16). While I think this is a nice idea, I think the hurdle is too large to do this quickly. [TRP]

Insert other comments on option #2 here.

==Option #3, Using <OR> as an OR separator, Using <AND> as an AND separator==

===Using Primitives===

CHOOSE:TEMPLATE|Template1<OR>Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo<OR>!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo<AND>!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo<OR>!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar<OR>TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo<OR>!TYPE=Bar]<OR>QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar]<AND>QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar<OR>TYPE=Goo]<OR>QUALIFIED<AND>!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

* Note that the unicode discussion here was broken out into option #4. - thpr Apr 4

*I Have a similar concern here to option #2, as we have not reserved < or > as restricted characters. < and > are used in actual data that we ship, and thus we would expect homebrews to feel this character is also legal. There is less risk of using (literally) <OR> or <AND>, which makes this somewhat safer than option #2. However, this does introduce restrictions on data naming. In order to implement this without risk, we end up having to have a Data Converter, as this will break existing PCs. (which is the open FREQ, not the item completed for 5.16). I think the hurdle is too large to do the FREQ converter quickly. [TRP]

*Do the characters '<' and '>' matter? Are there other characters that can't be used in a key name that can be used for identifying a logical operator? What about '$'? Are there any characters that we cannot use whatsoever for this? --[[User:Michael W. Fender|Fluxxdog]] 04:03, 1 April 2009 (CEST)

:* You may find the [[Data LST Standards]] useful to find reserved characters.
::*Not as helpful as you think. This just lists what should and shouldn't be used in our releases, not what actually can and can't be used.
::::*Not True: Characters which should never be used in object names are Commas (,), Pipes (|), Backslashes (\), Colons (:), Semicolons (;), Periods (.), Brackets ([]), Percent (%), Asterisk (*) and Equals (=). Perhaps we should change the language to "must not be used" to be more RFC 2119-like and avoid confusion. [TRP]
:::For example, we shouldn't use a backslash '\' but we can.
::::*I'm not convinced. Legality isn't defined by what parses cleanly. There are specific reasons each of those characters is prohibited. Try using backslash in a name inside a count() inside a Formula and see if it works. If that does work, I'd have to go code hunting to figure out what the case is that prohibits backslash, but it's on that list for a reason. [TRP]
:::::*...You don't know why? OK< just to test your challenge, I tried making a feat and having something else count() that number of times I took that feat. Problem is, it won't even let me take the feat. Possible safeguard? - Fluxxdog
:::DEFINE:Spaced\Variable|0 BONUS:VAR|Spaced\Variable|3 DESC:Here's the value: %1|Spaced\Variable
:::...still spits out "''Here's the value: 3''"--[[User:Michael W. Fender|Fluxxdog]] 23:35, 4 April 2009 (CEST)
:::I'll double back a bit. If we go the route of using our "shouldn't use" characters, what options do we have?
::::(snip - please read [[Data LST Standards]])
::::* The issue here is that the items prohibited from names are the ONLY characters we can use without writing a converter. [TRP]
:::None of these should be used as they already have other functions already.
::::*This is where the problem lies.
:::::* Depends on your definition of problem, but the point I have is that we either make sacrifices from the ideal, or we delay the conversion to these tokens until we can reach the ideal, which may be years away. I'd rather make sacrifices, which means using the characters on the prohibited list or getting REALLY wide agreement and community input that we can break datasets. [TRP]
::::::*That's my point. Who uses a backslash in their data sets? And the backslash isn't used anywhere else in LST files already. I'd say it's the ideal nominee for such an operation. - Fluxxdog
:::*Backslashes (\)
:::Curious thought, does anything actually use this? I don't think I've seen anything other than file names, which aren't used in LST files.
::::CHOOSE:TEMPLATE|Extra Weaponry\OR\Extra Appendage\OR\Extra Flavor\OR\Candle Power\OR\Super Eyesight
:::Unless a backslash is already being used, that doesn't look too bad itself. And it's highly unlikely, even more so than < and >, that it's used in LST files for even homebrews. It certainly isn't in our LST files now.--[[User:Michael W. Fender|Fluxxdog]] 02:32, 5 April 2009 (CEST)

* [nuance] I think the lower case version stands out better.

:* I'll definitely agree with nuance on using lowercase for 'and' and 'or'. Makes it so much more obvious.--[[User:Michael W. Fender|Fluxxdog]] 01:08, 2 April 2009 (CEST)

::* I happen to prefer the uppercase versions. - thpr 
:::One needs to consider also that these will often be used with Primitive objects, e.g.: 
:::CHOOSE:TEMPLATE|Extra Weaponry<or>Extra Appendage<or>Extra Flavor<or>Candle Power<or>Super Eyesight 
:::CHOOSE:TEMPLATE|Extra Weaponry<OR>Extra Appendage<OR>Extra Flavor<OR>Candle Power<OR>Super Eyesight 
:::... so I feel that the upper case keyword is far more consistent with our tokens (where the keywords like TEMPLATE, TYPE, etc. are all upper case) and also stand out more.
:::*How dare you use logic! ^^ But yeah, when you put it that way, we should stick to the standard of using CAPS for hardcoded words.--[[User:Michael W. Fender|Fluxxdog]] 23:35, 4 April 2009 (CEST)

*Just a tad bit of a summation here: If we use a character to denote the logical operators, the backslash '\' would seem the ideal choice as it's already restricted from being used in key names, so \AND\ and \OR\? Unless I'm misunderstanding you, Tom, out of the "don't use" list, this is the only one that's both
::A) not in use for some other purpose
::B) not in use for data sets
:If I'm wrong, please say so.--[[User:Michael W. Fender|Fluxxdog]] 16:26, 5 April 2009 (CEST)
Insert comments on option #3 here.

==Option #4, Leverage Unicode to use other separators, e.g. «OR» as an OR separator, Using «AND» as an AND separator==

Examples use lowercase

===Using Primitives===

CHOOSE:TEMPLATE|Template1«or»Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo«or»!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo«and»!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo«or»!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar«or»TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo«or»!TYPE=Bar]«or»QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar]«and»QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar«or»TYPE=Goo]«or»QUALIFIED«and»!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

* [nuance] LST files are UTF8, so theoretically we can use any unicode character. The problem with that is editor support—which it has to be said is getting better all the time. Since full unicde may be a bit of a shock , iso-8859-1 (latin 1) has « and » (alt0171 and alt0187 respectively). It also has ¿ (alt0191) which ties up nicely with ? if was want to wrap words.

:Of course, fully in the realm of unicode madness, we could always use ∧ for and, and ∨ for or, but the data folk might shoot us :-). Actually we could consider ^ to mean and, paired with |

::CHOOSE:TEMPLATE|PC[TYPE=Foo^!TYPE=Bar|TYPE=Goo]|QUALIFIED^!PC

::...allows a choice of:
::(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
::OR
::(b) Any Template that the PC is qualified to take, but has not yet taken.

:I think I prefer the last one, but I don't like the way | looks against ]. On this wiki ! is hard to distinguish from |, ¬ (shift ` on my keyboard) actually means not. I think using « and » in place of [ and ], and ¬ for not

::CHOOSE:TEMPLATE|PC«TYPE=Foo^¬TYPE=Bar|TYPE=Goo»|QUALIFIED^¬PC

:is easier to read but that might be a bit radical. Perhaps it's time we has that full reserved characters discussion.
:*Very true since we don't seem to have a full list (see above in option 3 about standards vs. actually allowed)--[[User:Michael W. Fender|Fluxxdog]] 23:58, 4 April 2009 (CEST)

*I'd like to move away from symbolism for words and actually use the words themselves. It makes it a lot easier for new people to read.--[[User:Michael W. Fender|Fluxxdog]] 01:08, 2 April 2009 (CEST)

*Using '«' and '»' is a good idea, but how exactly do you type that in? I think we should stick closer to what's available on the common keyboards without having to dig through a font list. Although, that gives me an idea... What about a character combinations?

:* [[User:Nuance|nuance]] Sorry if it was a bit opaque, but I gave instructions for how to type it (on a windows machine at least). Press and hold the "alt" key to the left of your space bar. Now, using the numeric keypad, type the numbers 0171, realease the "alt" key. Et viola «. » is similarly produced with the numbers 0187. Once you have one of them cut and paste is also an option. Since we aren't fully in the unicode realm here, most OSes have some way to type characters in the ios-8859-1 range.
::*I'm not saying it's a bad idea, I'm saying it's not a good idea. People will have to look into some kind of "tips and tricks" for their keyboard AND OS AND language AND font, since not every combination will work like that. Heck, tested it on 3 different programs on my system and it doesn't work at all. I think this is definitely a case of "the simpler the better".--[[User:Michael W. Fender|Fluxxdog]] 23:58, 4 April 2009 (CEST)

::: [http://en.wikipedia.org/wiki/Guillemets#Typing_.22.C2.AB.22_and_.22.C2.BB.22_on_computers| Typing the Guilemets « »]
:::*We'd have to include that link everytime «AND» or «OR» is included or put the information in the docs just to ensure everyone has that info when coding LST files. I'd say, at the very least, let's stick with characters that can't or shouldn't be used in Key names.--[[User:Michael W. Fender|Fluxxdog]] 02:19, 5 April 2009 (CEST)

:Hey coders! Could we do something along the lines of <<and>>? Using 2 '<' to signify a logical operator? Surely that must make things easier. -[[User:Michael W. Fender|Fluxxdog]] 01:08, 2 April 2009 (CEST)

:* Really doesn't make a huge difference. The < and > still aren't identified as reserved characters. It reduces the risk slightly, but it's probably small with <AND> and <OR> anyway. - thpr

Insert comments on option #4 here.

Separator Characters

2009-04-05T00:32:02Z

Michael W. Fender: /* Discussion */

{| align="right"
| __TOC__
|}

==Background==

There is an issue as far as long-term consistency for the use of characters to represent logical "AND" and "OR"

This document uses CHOOSE:TEMPLATE (since it doesn't exist) as an example. For additional CHOOSE tokens and proposals, you can see [[Architecture Changes 5.17]]

To readers: Please add additional options if you have additional ideas. You may find the [[Data LST Standards]] useful to look at reserved characters.

==Option #1, Using Pipe as an OR separator, Using Comma as an AND separator==

===Using Primitives===

CHOOSE:TEMPLATE|Template1|Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo|!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo,!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo|!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar|TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo|!TYPE=Bar]|QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar],QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar|TYPE=Goo]|QUALIFIED,!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

* Note that this is the existing syntax used in the CHOOSE proposals as they are shown on the Wiki. [TRP]
* Showing this syntax to a few non coders it definitely wasn't instinctively clear that ',' was an AND symbol. However, '|' was instinctively picked up as an OR symbol [[User:Karianna|karianna]] 18:59, 1 April 2009 (CEST)
* Part of that is that the pipe '|' just seems to break that attention naturally, which is why it works so well as a subtoken separator. But I think we should move away from giving two jobs to the same thing.--[[User:Michael W. Fender|Fluxxdog]] 01:12, 2 April 2009 (CEST)
Insert comments on option #1 here.

==Option #2, Using Comma as an OR separator, Using Ampersand as an AND separator==

===Using Primitives===

CHOOSE:TEMPLATE|Template1,Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo,!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo&!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar,TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo,!TYPE=Bar],QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar]&QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo&!TYPE=Bar,TYPE=Goo],QUALIFIED&!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

*I think this is a problem, as ampersand is not a reserved character in PCGen. This is used in actual data that we ship, and thus we would expect homebrews to feel this character is also legal. Therefore, in order to implement this properly, we end up having to have a Data Converter, as this will break existing PCs. (which is the open FREQ, not the item completed for 5.16). While I think this is a nice idea, I think the hurdle is too large to do this quickly. [TRP]

Insert other comments on option #2 here.

==Option #3, Using <OR> as an OR separator, Using <AND> as an AND separator==

===Using Primitives===

CHOOSE:TEMPLATE|Template1<OR>Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo<OR>!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo<AND>!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo<OR>!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar<OR>TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo<OR>!TYPE=Bar]<OR>QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar]<AND>QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo<AND>!TYPE=Bar<OR>TYPE=Goo]<OR>QUALIFIED<AND>!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

* Note that the unicode discussion here was broken out into option #4. - thpr Apr 4

*I Have a similar concern here to option #2, as we have not reserved < or > as restricted characters. < and > are used in actual data that we ship, and thus we would expect homebrews to feel this character is also legal. There is less risk of using (literally) <OR> or <AND>, which makes this somewhat safer than option #2. However, this does introduce restrictions on data naming. In order to implement this without risk, we end up having to have a Data Converter, as this will break existing PCs. (which is the open FREQ, not the item completed for 5.16). I think the hurdle is too large to do the FREQ converter quickly. [TRP]

*Do the characters '<' and '>' matter? Are there other characters that can't be used in a key name that can be used for identifying a logical operator? What about '$'? Are there any characters that we cannot use whatsoever for this? --[[User:Michael W. Fender|Fluxxdog]] 04:03, 1 April 2009 (CEST)

:* You may find the [[Data LST Standards]] useful to find reserved characters.
::*Not as helpful as you think. This just lists what should and shouldn't be used in our releases, not what actually can and can't be used. For example, we shouldn't use a backslash '\' but we can.
:::DEFINE:Spaced\Variable|0 BONUS:VAR|Spaced\Variable|3 DESC:Here's the value: %1|Spaced\Variable
:::...still spits out "''Here's the value: 3''"--[[User:Michael W. Fender|Fluxxdog]] 23:35, 4 April 2009 (CEST)
:::I'll double back a bit. If we go the route of using our "shouldn't use" characters, what options do we have?
:::*Commas (,)
:::*Pipes (|)
:::*Colons (:)
:::*Semicolons (;)
:::*Periods (.)
:::*Brackets ([])
:::*Percent (%)
:::*Asterisk (*)
:::*Equals (=)
:::None of these should be used as they already have other functions already.
:::*Backslashes (\)
:::Curious thought, does anything actually use this? I don't think I've seen anything other than file names, which aren't used in LST files.
::::CHOOSE:TEMPLATE|Extra Weaponry\OR\Extra Appendage\OR\Extra Flavor\OR\Candle Power\OR\Super Eyesight
:::Unless a backslash is already being used, that doesn't look too bad itself. And it's highly unlikely, even more so than < and >, that it's used in LST files for even homebrews. It certainly isn't in our LST files now.--[[User:Michael W. Fender|Fluxxdog]] 02:32, 5 April 2009 (CEST)

* [nuance] I think the lower case version stands out better.

:* I'll definitely agree with nuance on using lowercase for 'and' and 'or'. Makes it so much more obvious.--[[User:Michael W. Fender|Fluxxdog]] 01:08, 2 April 2009 (CEST)

::* I happen to prefer the uppercase versions. - thpr 
:::One needs to consider also that these will often be used with Primitive objects, e.g.: 
:::CHOOSE:TEMPLATE|Extra Weaponry<or>Extra Appendage<or>Extra Flavor<or>Candle Power<or>Super Eyesight 
:::CHOOSE:TEMPLATE|Extra Weaponry<OR>Extra Appendage<OR>Extra Flavor<OR>Candle Power<OR>Super Eyesight 
:::... so I feel that the upper case keyword is far more consistent with our tokens (where the keywords like TEMPLATE, TYPE, etc. are all upper case) and also stand out more.
:::*How dare you use logic! ^^ But yeah, when you put it that way, we should stick to the standard of using CAPS for hardcoded words.--[[User:Michael W. Fender|Fluxxdog]] 23:35, 4 April 2009 (CEST)
Insert comments on option #3 here.

==Option #4, Leverage Unicode to use other separators, e.g. «OR» as an OR separator, Using «AND» as an AND separator==

Examples use lowercase

===Using Primitives===

CHOOSE:TEMPLATE|Template1«or»Template2

...allows a choice of Template1 or Template2

CHOOSE:TEMPLATE|TYPE=Foo«or»!TYPE=Bar

...allows a choice of any Template that is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|TYPE=Foo«and»!TYPE=Bar

...allows a choice of any Template that is both TYPE=Foo and not TYPE=Bar

===Using Single a Qualifier===

CHOOSE:TEMPLATE|PC[TYPE=Foo«or»!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar]

...allows a choice of any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar«or»TYPE=Goo]

...allows a choice of any Template that the character already has, where the Template is (a) both TYPE=Foo and not TYPE=Bar OR (b) TYPE=Goo

===Using Multiple Qualifiers===

CHOOSE:TEMPLATE|PC[TYPE=Foo«or»!TYPE=Bar]«or»QUALIFIED[TYPE=Goo]

...allows a choice of
(a) Any Template that the character already has, where the Template is either TYPE=Foo or not TYPE=Bar
OR
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar]«and»QUALIFIED[TYPE=Goo]

...allows a choice of:
(a) Any Template that the character already has, where the Template is both TYPE=Foo and not TYPE=Bar
AND
(b) Any Template the PC is qualified to take that is TYPE=Goo

CHOOSE:TEMPLATE|PC[TYPE=Foo«and»!TYPE=Bar«or»TYPE=Goo]«or»QUALIFIED«and»!PC

...allows a choice of:
(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
OR
(b) Any Template that the PC is qualified to take, but has not yet taken.

===Discussion===

* [nuance] LST files are UTF8, so theoretically we can use any unicode character. The problem with that is editor support—which it has to be said is getting better all the time. Since full unicde may be a bit of a shock , iso-8859-1 (latin 1) has « and » (alt0171 and alt0187 respectively). It also has ¿ (alt0191) which ties up nicely with ? if was want to wrap words.

:Of course, fully in the realm of unicode madness, we could always use ∧ for and, and ∨ for or, but the data folk might shoot us :-). Actually we could consider ^ to mean and, paired with |

::CHOOSE:TEMPLATE|PC[TYPE=Foo^!TYPE=Bar|TYPE=Goo]|QUALIFIED^!PC

::...allows a choice of:
::(a) Any Template that the character already has, where the Template is (a1) both TYPE=Foo and not TYPE=Bar OR (a2) TYPE=Goo
::OR
::(b) Any Template that the PC is qualified to take, but has not yet taken.

:I think I prefer the last one, but I don't like the way | looks against ]. On this wiki ! is hard to distinguish from |, ¬ (shift ` on my keyboard) actually means not. I think using « and » in place of [ and ], and ¬ for not

::CHOOSE:TEMPLATE|PC«TYPE=Foo^¬TYPE=Bar|TYPE=Goo»|QUALIFIED^¬PC

:is easier to read but that might be a bit radical. Perhaps it's time we has that full reserved characters discussion.
:*Very true since we don't seem to have a full list (see above in option 3 about standards vs. actually allowed)--[[User:Michael W. Fender|Fluxxdog]] 23:58, 4 April 2009 (CEST)

*I'd like to move away from symbolism for words and actually use the words themselves. It makes it a lot easier for new people to read.--[[User:Michael W. Fender|Fluxxdog]] 01:08, 2 April 2009 (CEST)

*Using '«' and '»' is a good idea, but how exactly do you type that in? I think we should stick closer to what's available on the common keyboards without having to dig through a font list. Although, that gives me an idea... What about a character combinations?

:* [[User:Nuance|nuance]] Sorry if it was a bit opaque, but I gave instructions for how to type it (on a windows machine at least). Press and hold the "alt" key to the left of your space bar. Now, using the numeric keypad, type the numbers 0171, realease the "alt" key. Et viola «. » is similarly produced with the numbers 0187. Once you have one of them cut and paste is also an option. Since we aren't fully in the unicode realm here, most OSes have some way to type characters in the ios-8859-1 range.
::*I'm not saying it's a bad idea, I'm saying it's not a good idea. People will have to look into some kind of "tips and tricks" for their keyboard AND OS AND language AND font, since not every combination will work like that. Heck, tested it on 3 different programs on my system and it doesn't work at all. I think this is definitely a case of "the simpler the better".--[[User:Michael W. Fender|Fluxxdog]] 23:58, 4 April 2009 (CEST)

::: [http://en.wikipedia.org/wiki/Guillemets#Typing_.22.C2.AB.22_and_.22.C2.BB.22_on_computers| Typing the Guilemets « »]
:::*We'd have to include that link everytime «AND» or «OR» is included or put the information in the docs just to ensure everyone has that info when coding LST files. I'd say, at the very least, let's stick with characters that can't or shouldn't be used in Key names.--[[User:Michael W. Fender|Fluxxdog]] 02:19, 5 April 2009 (CEST)

:Hey coders! Could we do something along the lines of <<and>>? Using 2 '<' to signify a logical operator? Surely that must make things easier. -[[User:Michael W. Fender|Fluxxdog]] 01:08, 2 April 2009 (CEST)

:* Really doesn't make a huge difference. The < and > still aren't identified as reserved characters. It reduces the risk slightly, but it's probably small with <AND> and <OR> anyway. - thpr

Insert comments on option #4 here.

Separator Characters

2009-04-05T00:19:32Z

Michael W. Fender: /* Discussion */

Separator Characters

2009-04-04T21:58:25Z

Michael W. Fender: /* Discussion */

Separator Characters

2009-04-04T21:35:37Z

Michael W. Fender: /* Discussion */

Separator Characters

2009-04-01T23:12:29Z

Michael W. Fender: /* Discussion */

Separator Characters

2009-04-01T23:08:04Z

Michael W. Fender: /* Discussion */

Separator Characters

2009-04-01T02:03:58Z

Michael W. Fender: /* Discussion */

Michael W. Fender

2009-02-08T03:15:23Z

Michael W. Fender:

Joined October 17, 2008

'''Additional Contact info:'''
 GTalk: fluxxdog@gmail.com
 MSN: fluxxdog@bellsouth.net
 E-Mail: fluxxdog@gmail.com

'''Current projects:'''
 2474790 - AEG - Feats Source Book - Reveiw & Clean up

'''Completed projects:'''
 2175540 - Psionic Talent Feat grants +0 PP instead of +2
 2181056 - [MSRD] SEP - Roles and Classes - Combat Hero - cleanup
 2181063 - RPGObjects - Blood and Circuits - Data Clean Up
 2181069 - RPGObjects - B&G - Inside Vossberg Supermax - clean up
 2181071 - RPGObjects - Blood and Guts - Modern Military - Clean up
 2181073 - RPGObjects - Blood and Guts - Soldiers - Clean up
 2181076 - RPGObjects - Blood and Guts - War on Terror - Clean Up
 2181082 - RPGO - Blood & Space - Merchants Pirates & Smuggler - Clean
 2181094 - RPGO - Blood & Space - Starship Construction Manual - Clean
 2181098 - Blood & Blades - The Profilers Guide to Slashers - Clean Up
 2181100 - Dawning Star - Operation Quick Launch - Clean Up
 2181105 - Modern Dispatch - #47 - New Tortuga - Clean Up
 2181108 - Pulp Fantasy Roleplaying Game - Clean Up
 2181111 - RPGObjects - Blood and Relics - Clean Up
 2181119 - WotC - d20 Modern Weapons Locker - Clean Up
 2185729 - Referencing an outside source causes confusion
 2220150 - [RSRD] Certain languages missing "Read.Written" types
 2182525 - ACHECK listed twice
 2229773 - Incorrect JEP syntax in CASTERLEVEL BONUS
 1377456 - [Core datasets] Temp bonus for Spells audit

'''Projects I assisted with:'''
 2158412 - Change "Turn Rebuke" from specific instances to general

Michael W. Fender

2009-02-08T03:14:52Z

Michael W. Fender:

Joined October 17, 2008

'''Additional Contact info:'''
 GTalk: fluxxdog@gmail.com
 MSN: fluxxdog@bellsouth.net
 E-Mail: fluxxdog@gmail.com

'''Current projects:'''
 2474790 - AEG - Feats Source Book - Reveiw & Clean up
 1377456 - Temp bonus for Spells audit

'''Completed projects:'''
 2175540 - Psionic Talent Feat grants +0 PP instead of +2
 2181056 - [MSRD] SEP - Roles and Classes - Combat Hero - cleanup
 2181063 - RPGObjects - Blood and Circuits - Data Clean Up
 2181069 - RPGObjects - B&G - Inside Vossberg Supermax - clean up
 2181071 - RPGObjects - Blood and Guts - Modern Military - Clean up
 2181073 - RPGObjects - Blood and Guts - Soldiers - Clean up
 2181076 - RPGObjects - Blood and Guts - War on Terror - Clean Up
 2181082 - RPGO - Blood & Space - Merchants Pirates & Smuggler - Clean
 2181094 - RPGO - Blood & Space - Starship Construction Manual - Clean
 2181098 - Blood & Blades - The Profilers Guide to Slashers - Clean Up
 2181100 - Dawning Star - Operation Quick Launch - Clean Up
 2181105 - Modern Dispatch - #47 - New Tortuga - Clean Up
 2181108 - Pulp Fantasy Roleplaying Game - Clean Up
 2181111 - RPGObjects - Blood and Relics - Clean Up
 2181119 - WotC - d20 Modern Weapons Locker - Clean Up
 2185729 - Referencing an outside source causes confusion
 2220150 - [RSRD] Certain languages missing "Read.Written" types
 2182525 - ACHECK listed twice
 2229773 - Incorrect JEP syntax in CASTERLEVEL BONUS
 1377456 - [Core datasets] Temp bonus for Spells audit

'''Projects I assisted with:'''
 2158412 - Change "Turn Rebuke" from specific instances to general

Michael W. Fender

2009-01-07T05:30:43Z

Michael W. Fender:

Joined October 17, 2008

'''Additional Contact info:'''
 GTalk: fluxxdog@gmail.com
 MSN: fluxxdog@bellsouth.net
 E-Mail: fluxxdog@gmail.com

'''Current projects:'''
 2474790 - AEG - Feats Source Book - Reveiw & Clean up
 1377456 - Temp bonus for Spells audit

'''Completed projects:'''
 2175540 - Psionic Talent Feat grants +0 PP instead of +2
 2181056 - [MSRD] SEP - Roles and Classes - Combat Hero - cleanup
 2181063 - RPGObjects - Blood and Circuits - Data Clean Up
 2181069 - RPGObjects - B&G - Inside Vossberg Supermax - clean up
 2181071 - RPGObjects - Blood and Guts - Modern Military - Clean up
 2181073 - RPGObjects - Blood and Guts - Soldiers - Clean up
 2181076 - RPGObjects - Blood and Guts - War on Terror - Clean Up
 2181082 - RPGO - Blood & Space - Merchants Pirates & Smuggler - Clean
 2181094 - RPGO - Blood & Space - Starship Construction Manual - Clean
 2181098 - Blood & Blades - The Profilers Guide to Slashers - Clean Up
 2181100 - Dawning Star - Operation Quick Launch - Clean Up
 2181105 - Modern Dispatch - #47 - New Tortuga - Clean Up
 2181108 - Pulp Fantasy Roleplaying Game - Clean Up
 2181111 - RPGObjects - Blood and Relics - Clean Up
 2181119 - WotC - d20 Modern Weapons Locker - Clean Up
 2185729 - Referencing an outside source causes confusion
 2220150 - [RSRD] Certain languages missing "Read.Written" types
 2182525 - ACHECK listed twice
 2229773 - Incorrect JEP syntax in CASTERLEVEL BONUS

'''Projects I assisted with:'''
 2158412 - Change "Turn Rebuke" from specific instances to general

Michael W. Fender

2009-01-07T05:00:12Z

Michael W. Fender:

Joined October 17, 2008

'''Additional Contact info:'''
 GTalk: fluxxdog@gmail.com
 MSN: fluxxdog@bellsouth.net
 E-Mail: fluxxdog@gmail.com

'''Current projects:'''
 2474790 - AEG - Feats Source Book - Reveiw & Clean up
 1377456 - Temp bonus for Spells audit

'''Completed projects:'''
 2175540 - Psionic Talent Feat grants +0 PP instead of +2
 2181056 - [MSRD] SEP - Roles and Classes - Combat Hero - cleanup
 2181063 - RPGObjects - Blood and Circuits - Data Clean Up
 2181069 - RPGObjects - B&G - Inside Vossberg Supermax - clean up
 2181071 - RPGObjects - Blood and Guts - Modern Military - Clean up
 2181073 - RPGObjects - Blood and Guts - Soldiers - Clean up
 2181076 - RPGObjects - Blood and Guts - War on Terror - Clean Up
 2181082 - RPGO - Blood & Space - Merchants Pirates & Smuggler - Clean
 2181094 - RPGO - Blood & Space - Starship Construction Manual - Clean
 2181098 - Blood & Blades - The Profilers Guide to Slashers - Clean Up
 2181100 - Dawning Star - Operation Quick Launch - Clean Up
 2181105 - Modern Dispatch - #47 - New Tortuga - Clean Up
 2181108 - Pulp Fantasy Roleplaying Game - Clean Up
 2181111 - RPGObjects - Blood and Relics - Clean Up
 2181119 - WotC - d20 Modern Weapons Locker - Clean Up
 2185729 - Referencing an outside source causes confusion
 2220150 - [RSRD] Certain languages missing "Read.Written" types
 2182525 - ACHECK listed twice
 2229773 - Incorrect JEP syntax in CASTERLEVEL BONUS
 2491524 - ADD: does not accept PRExxx tags

'''Projects I assisted with:'''
 2158412 - Change "Turn Rebuke" from specific instances to general

Michael W. Fender

2009-01-07T01:47:36Z

Michael W. Fender:

Joined October 17, 2008

'''Additional Contact info:'''
 GTalk: fluxxdog@gmail.com
 MSN: fluxxdog@bellsouth.net
 E-Mail: fluxxdog@gmail.com

'''Current projects:'''
 2474790 - AEG - Feats Source Book - Reveiw & Clean up
 1377456 - Temp bonus for Spells audit

'''Completed projects:'''
 2175540 - Psionic Talent Feat grants +0 PP instead of +2
 2181056 - [MSRD] SEP - Roles and Classes - Combat Hero - cleanup
 2181063 - RPGObjects - Blood and Circuits - Data Clean Up
 2181069 - RPGObjects - B&G - Inside Vossberg Supermax - clean up
 2181071 - RPGObjects - Blood and Guts - Modern Military - Clean up
 2181073 - RPGObjects - Blood and Guts - Soldiers - Clean up
 2181076 - RPGObjects - Blood and Guts - War on Terror - Clean Up
 2181082 - RPGO - Blood & Space - Merchants Pirates & Smuggler - Clean
 2181094 - RPGO - Blood & Space - Starship Construction Manual - Clean
 2181098 - Blood & Blades - The Profilers Guide to Slashers - Clean Up
 2181100 - Dawning Star - Operation Quick Launch - Clean Up
 2181105 - Modern Dispatch - #47 - New Tortuga - Clean Up
 2181108 - Pulp Fantasy Roleplaying Game - Clean Up
 2181111 - RPGObjects - Blood and Relics - Clean Up
 2181119 - WotC - d20 Modern Weapons Locker - Clean Up
 2185729 - Referencing an outside source causes confusion
 2220150 - [RSRD] Certain languages missing "Read.Written" types
 2182525 - ACHECK listed twice
 2229773 - Incorrect JEP syntax in CASTERLEVEL BONUS

'''Projects I assisted with:'''
 2158412 - Change "Turn Rebuke" from specific instances to general

Michael W. Fender

2008-10-21T20:30:31Z

Michael W. Fender: New page: Joined October 17, 2008

Joined October 17, 2008

Full Team Member Listing

2008-10-20T21:33:24Z

Michael W. Fender: /* Active Volunteers */

{| align="right"
| __TOC__
|}

=Introduction=

PCGen has been blessed with an amazing amount of volunteers over the course of its history. A historical listing of those who have contributed (past and present) can be seen in the [http://pcgen.sourceforge.net/autobuilds/pcgen-docs/acknowledgments/contributors.html Contributors] section of our Documentation. The current team is listed below:

=Active Volunteers=
These volunteers are currently active on the PCGen project

{| border="1"
|-
! align="left"|SF Team Name !! align="left"|Real Name !! align="left"|SF ID !! align="left"|Yahoo ID !! align="left"|AIM ID !! align="left"|ICQ !! align="left"|Teams
|-
| Aaron Divinsky || Aaron Divinsky || boomer70 || boomer70 || - || - || C
|-
| [[Alec Ross]] || [[Alec Ross]] || haelduksf || haelduksf || haelduksf || 50824602 || C
|-
| [[Andargor]] || - || Andargor || andargor || - || - || C, Da
|-
| Anestis Kozakis || Anestis Kozakis || kenosti || xeno_h || Xeno1970 || 837313 || B, W
|-
| [[Tir Gwaith|Andrew McDougall]] || [[Tir Gwaith|Andrew McDougall]] || tir-gwaith || tir_gwaith || TirGwaith || - || Ad, C, Da, Do, DL, R, O, T
|-
| Andrew Wilson || Andrew Wilson || nuance || ytitendi || - || - || C
|-
| apsen || Andriy Sen || apsen || - || - || - || C
|-
| Bart || Bart Rompelman || necrodeath || - || - || - || T
|-
| Brad Stiles || Brad Stiles || bsmeister || - || - || - || C, R
|-
| Brian || - || telechus || - || - || - || -
|-
| Chad || - || litesgod || - || - || - || -
|-
| Charles || Chuck Hazard || chuckhazard || - || - || - || -
|-
| [[Chris Chandler|Barak]] || [[Chris Chandler]] || barako || Barak20021 || - || - || Da,Do,O
|-
| Chuck Pint || Chuck Pint || chuckpint || chuckpint || - || - || O
|-
| [[Connor Petty]] || [[Connor Petty]] || cpmeister || mistercpp2000 || MrBooyah314 || - || A, C
|-
| Dave Cheever || David Cheever || takeyabue || - || - || - || Do
|-
| David || David Rosenthal || rimbeaux || - || - || - || W
|-
| David Lim || David Lim || aberrant80 || aberrant80 || - || - || -
|-
| [[David R. Bender]] || [[David R. Bender]] || papa_drb || Papa_DRB || - || - || Da
|-
| Dennis Baker || Dennis Baker || mtbOgre || - || mtbogre || - || Da
|-
| Dracorat || Keith Ratliff || dracorat || - || - || - || -
|-
| [[Eddy Anthony]] || [[Eddy Anthony]] || eddyanthony || eddyanthony || - || - || B, C, Da, Do, O, R, T
|-
| Edwin C Holley || Edwin C Holley || glasswalker || GlassWalkerTheurge1968 || - || - || -
|-
| [[Terry FitzSimons|Fitzs]] || [[Terry FitzSimons]] || fitzs || Fitzsimons_T_J || - || - || Da, Do
|-
| Fluxxdog || Michael W. Fender || fluxxdog || fluxxdog || fluxxdog || 346992562 || Da, Do, O, T
|-
| [[Frank Kliewe]] || [[Frank Kliewe]] || frank_kliewe || frank_kliewe || - || - || Da, Do, O, T
|-
| [[Greg Bingleman]] || [[Greg Bingleman]] || byngl || gsbingl || - || - || C
|-
| [[James Dempsey]] || [[James Dempsey]] || jdempsey || james_dempsey_au || tallandir || 21047253 || C, R
|-
| Jason Buchanan || Jason Buchanan || lonejedi || - || CMPLoneJedi70 || - || -
|-
| [[Jason Horner]] || [[Jason Horner]] || jlhorner1974 || jlhorner1974 || - || - || Da, O
|-
| Jayme Cox || Jayme Cox || jaymecox || - || - || - || -
|-
| [[Jonas Karlson|Jonas Karlsson]] || [[Jonas Karlson|Jonas Karlsson]] || jujutsunerd || pjak || jonask42 || 2345481 || C
|-
| Julio Esslinger Viegas || Julio Esslinger Viegas || julio_ev || - || - || - || -
|-
| [[Kent Behrends]] || [[Kent Behrends]] || bci || kent_behrends || KentAtBci || - || -
|-
| [[Koen Van Daele]] || [[Koen Van Daele]] || vandaelek || koen_van_daele || Kador99 || - || C
|-
| [[LegacyKing]] || [[LegacyKing|Andrew Maitland]] || amaitland || paramedic4553 || drew0500 || 5830737 || B,Da,Do,T,W
|-
| [[Martijn Verburg]] || [[Martijn Verburg]] || karianna || karianna03 || karianna02 || - || B, C, Da, Do, O, T
|-
| [[Eric C Smith|Maredudd]] || [[Eric C Smith]] || maredudd800 || maredudd800 || Maredudd || - || Ad,B,Da,Do,DL,P,T,W
|-
| Mike || - || javadrinker || - || - || - || -
|-
| Michael Gray || Michael Gray || mhgj || - || - || - || -
|-
| Paul Grosse || Paul Grosse || nylanfs || Nylanfs || Nylan8 || 14397299 || B, Da, DL, O, T, W
|-
| [[Paul W. King]] || [[Paul W. King]] || kingpaul || pkingdnd || ShutUpPaul || - || B, Da, DL, O, P, T
|-
| Peter Barker || Peter Barker || pjdb || - || - || - || -
|-
| Phantom of Krankor || Phantom of Krankor || y2krankor || - || - || - || Da
|-
| Phillip Ryan || Phillip Ryan || HistoryPhil || phillipryan49 || - || - || Da
|-
| Reed Thornton || Reed Thornton || rthornton13 || - || - || - || -
|-
| [[Rick Ryker]] || [[Rick Ryker]] || kerrik || rick_ryker || Rick Ryker || - || C
|-
| Robert Ward || Robert Ward || rward30 || rward_30 || - || - || R
|-
| Schporto || Chris Donohue || chrisdonohue || - || - || - || -
|-
| [[Shelley Stephen|Shelley]] || [[Shelley Stephen]] || takenote61 || takenote61 || takenote61 || - || Da
|-
| Sigurdur H. Olafsson || Sigurdur H. Olafsson || sholafsson || - || - || - || -
|-
| [[Stefan Radermacher]] || [[Stefan Radermacher]] || zaister || zaister || - || 6510566 || C, Da, Do
|-
| Theryon Stormrune || David T Jacobson || shadowcat || - || - || - || -
|-
| Thomas Clegg || Thomas Clegg || arknight || - || - || - || -
|-
| Tistur || Miriam Sexton || tistur || gryphondreams || tistur || - || -
|-
| tlavalle || Tony Lavalle || tlavalle || - || - || - || -
|-
| [[Tod Milam]] || [[Tod Milam]] || tmilam || twmilam || - || - || C, Da, R
|-
| [[Tom Parker]] || [[Tom Parker]] || thpr || thpr || - || - || A, B, C
|-
| Tymophil || - || tymophil_fr || - || - || - || -
|-
| Vincent || Vincent Yanda || lunaticlord || lunaticlord || - || - || -
|}

=Passive Volunteers=
These volunteers are currently passive on the PCGen project, that usually means they have insightful things to say on our internal mailing lists, but don't have enough time left over from RL to add code etc :).

{| border="1"
|-
! align="left"|SF Team Name !! align="left"|Real Name !! align="left"|SF ID !! align="left"|Yahoo ID !! align="left"|AIM ID !! align="left"|ICQ !! align="left"|Teams
|-
| Paul M. Lambert || Paul M. Lambert || plambert || - || - || - || -
|}

=Inactive Volunteers=
These volunteers are currently inactive on the PCGen project
'''Don't ever delete these people from SF though!'''
{| border="1"
|-
! align="left"|SF Team Name !! align="left"|Real Name !! align="left"|SF ID !! align="left"|Yahoo ID !! align="left"|AIM ID !! align="left"|ICQ !! align="left"|Teams
|-
| Bill || Bill Neumann || lodivigo || - || - || - || -
|-
| Briarius || Brian Spurling || briarius || sirbriarius || SirBriari1 || 9007056 || -
|-
| '''[[Bryan McRoberts]]''' || '''[[Bryan McRoberts]]''' || '''merton_monk''' || '''merton_monk''' || - || - || '''B,C'''
|-
| [[Charles Burkett]] || [[Charles Burkett]] || Kyth || Charlesb_06 || Phule50000 || - || Do, P
|-
| David Saulnier || David Saulnier || dsaulinar || - || - || - || Da
|-
| deltadave || David Lockwood || deltadave || roninkelt || deltadave || - || -
|-
| Devon Jones || Devon Jones || soulcatcher || hunterd_us || - || - || A,B,C
|-
| [[Eduard Martinescu]] || [[Eduard Martinescu]] || arvoreen || - || - || - || C
|-
| Eric Jarman || Eric Jarman || oracleofbargth || - || - || - || C, Da
|-
| gawaine42 || Richard Bowers || gawaine42 || richardsbowers || richardsbowers || - || O
|-
| [[Joe Frazier, Jr.]] || [[Joe Frazier, Jr.]] || jfrazierjr || joefrazierjr || jfrazierjr || - || C
|-
| John Zittlau || John Zittlau || naarok || naarok || naarok17 || - || -
|-
| Josh || Josh Johnston || pucspifo || - || - || - || -
|-
| [[Kevin Fernandes]] || [[Kevin Fernandes]] || darkstorm999 || kevin_fernandes01453 || darkstorm0000 || - || C
|-
| Kurt Wimmer || Kurt Wimmer || kwimmer || - || - || - || C
|-
| Michael Beaver || Michael Beaver || michaelbeaver || - || - || - || B
|-
| Michael Durant || Michael Durant || miked_msn || miked_msn || - || - || Do
|-
| PK Lucas || PK Lucas || pklucas || pklucas || - || - || -
|-
| Per Christian Henden || Per Christian Henden || perchrh || perchrh || - || 48325984 || C
|-
| Ratheof Blithwyn || Anders Lindgren || blithwyn || - || - || - || Da
|-
| Walter Duncan || Walter Duncan || wduncan || - || - || - || C
|-
| Walter Duncan || Walter Duncan || pcgen_autobuild || - || - || - || C
|}

=Teams Key=

{| border="1"
|-
! align="left"|Key !! align="left"|Team
|-
| A || [[Architecture]]
|-
| Ad || [[Advertising]]
|-
| B || [[Board of Directors]]
|-
| C || [[Code]]
|-
| Da || [[Data]]
|-
| Do || [[Documentation]]
|-
| DL || [[Data License]]
|-
| O || [[Output Sheets]]
|-
| P || [[Publisher Liaison]]
|-
| R || [[Release]]
|-
| T || [[Tracker]]
|-
| W || [[Website]]
|}