I think idea is good, but there are several problems with initial
proposal that need some resolution:
1. N property
Property N is inteded to be user-visible and editable name for node. So
duplicated exists, and preventing user from giving same node name twice
in file is bad solution.
I think it would be better to define some other property (for example
AC[ int ]), that could be used to reference node in all cases it is
machine referenced. (I have planned such id for other uses, but I would
prefer having single standard one.)
Proposal: define new invisible-to-user property AC[nro] for node, and
use that to reference to node.
I would like to say loops are not allowed, bu:
If we consider following chain of editing
1. create file which contain new properties;
2. edit file with editor that does not know new properties (they
continue to exists a long time).
3. Open file again with editor understanding new properties.
Now at step 3 we may have loops, as at step 2 there is no way new rules
are followed, even though editor was SGF4-compliant.
So I think we should not add new restrictions to what is valid file.
Loops will exists, and programs need to be able to deal with them.
Also nodes with TP might not be leaf nodes anymore.
So in essence new limitations would invalidate SGF4-compliance of
program, which is exactly what standards are supposed to prevent.
Proposal: No new restrictions to SGF4 file structure.
3. Link interpretation
I think we should have 2 types of links:
- Just jump to location, as user would have moved to location (so TP
does not need to be leaf)
- Continue with referenced subtree, as proposed here.
Arno Hollosi wrote:
>> The SGF file format has succeeded by being a file format. Specifying
>> the way a program interacts with a user should be left up the program
> Sometimes the GUI or interaction with the user has to be addressed in
> the specification. That's the reason why we have a ST property. I am
> just trying to find out if someone thinks there may be issues.
>> I hope/imagine that most programs will make the presence or
>> absence of N's and TP's invisible to the user.
> I think that depends. When I am editing I'd like to know whether my
> change is copied multiple times within the SGF tree or is a local
> modification only. Furthermore, when I know that the subtree is copied
> (and maybe transformed) I know that I should avoid comments like "upper
> right corner" or "B5 should be at C17".
> SGF spec: http://www.red-bean.com/sgf/
> Contact: Arno Hollosi <ahollosi@...>Yahoo! Groups Links