Re: [tw5] Re: Unrestricted field names... an implied use case

[TW Tones]

Folks,

I have constructed various fieldnames over the years that make use of 
naming standards such as menu-item1  menu-item2 or 
link/named-link/another-link where my code can find all fields on the 
current tiddler or throughout the wiki say with the suffix "-link" and then 
determines the prefix and returns that as a value eg; the link "another" 
containing the url found in another-link. 

In the above cases you can see the hyphen acting as a delimiter, with the 
lifting of naming restrictions on fieldnames I can see being able to use 
other delimiters such as : or even :link, I really like this freedom, but 
also wonder if we should preempt such flexibility with some de facto 
standards that we tend to use, eg in the above "link" is naming a field 
"type" in the name of the field. fieldname:link and we use link to identify 
how to display that fieldname eg; inside a html  element.

I am also keen to have a de facto standard so we can build index tables in 
tiddlers for one to one, one to many or many to many relationships. For 
example fieldname:indextiddlername where the value(s) in such a field is a 
key to an index tiddler "indextiddlername" that contains one (or more) 
entries for that key, the entries may be values or "other tidder" names 
(other keys). The "other tiddlers" could also access the index.

Although these structures can be already emulated in tiddlywiki with such 
de facto standards we can build sharable tools to support such 
sophisticated relationships. Do it once share and reuse many times.

With carful use such structures could help with the performance of 
tiddlywiki when building larger and more sophisticated 
relationships/databases, while in a way stepping to the side of the tiddler 
refresh cycle.

Regards
Tones

On Friday, 18 June 2021 at 02:30:27 UTC+10 springer wrote:

> Jeremy and all,
>
> I too am *very* excited about this, especially given my dependence on 
> dynamic tables. 
>
> First, a small confession: I've already been using short special-character 
> fieldnames for a while, sneaking around the protection by setting them up 
> as column names in Shiraz dynamic tables, and then editing those tables. 
> One use: column headings like § and @ that allow for compact and intuitive 
> presentation, when the column data tends to be single-digit. But this is a 
> superficial cheat (since these have been old-fashioned property-like 
> fields).
>
> More importantly, isn't this v5.2.0 step a path to more powerful 
> (multi-dimensional) relational data, or at least virtual pivot-table 
> behavior? 
>
> Suppose a use-case that involves spread-sheet-like relation between 
> tiddlers (rows) and fields (columns), where the field-names tend to have 
> their own tiddlers (which until now we've named in the constrained way) 
>
> Starting wth v5.2.0, can't field names can serve better as the 
> intersection (cell) of these two dimensions? Values at the intersection 
> should be more readily accessed via either axis of the table, so that what 
> appears in Tiddler A, field F, also *could* be referenced easily within 
> tiddler F (That is, F can be set up with filters to draw info from all 
> tiddlers that use F as a field name). 
>
> I imagine the intersectional-field-data housed remotely (on the other 
> "axis") could be rendered like virtual fields (within a filter-condition 
> ViewTemplate)... and it may even be possible to reach through and edit the 
> remote intersection-field directly.
>
> For true pivot-table purposes, a plugin could flag or help correct 
> discrepancies between A's F-value and F's A-value, no?Obviously, this would 
> have to be an optional feature, or one that hangs on some further 
> condition, since some uses might call for A's F-value to differ from F's 
> A-value -- especially on legacy projects built without intersectional power 
> in mind.
>
> I welcome corrections or clarifications from those who actually understand 
> the guts of TW5!
>
> -Springer
> On Thursday, June 17, 2021 at 5:54:02 AM UTC-4 jeremy...@gmail.com wrote:
>
>> One thing to bear in mind is that the core has always supported 
>> unrestricted fieldnames for almost all operations. The primary thing that's 
>> changing now is that the switch to the JSON store area allows us to 
>> guarantee that arbitrary fieldnames will be respected over a 
>> save-and-reload cycle. The secondary thing is the removal of the very weak 
>> protections against creating fieldnames containing arbitrary characters.
>>
>> Perhaps there a relatively small number of usecases for complex 
>> fieldnames, but some of those use cases are powerful and so seem important. 
>> But even in the absence of important use cases, a very important benefit is 
>> that unrestricted fieldnames make TiddlyWiki significantly simpler to 
>> explain. Every little arbitrary restriction or caveat adds to the 
>> conceptual load for people learning TiddlyWiki.
>>
>> For me, one of the most important consequences is that we can encode 

Re: [tw5] Re: Unrestricted field names... an implied use case

[springer]

Jeremy and all,

I too am *very* excited about this, especially given my dependence on 
dynamic tables. 

First, a small confession: I've already been using short special-character 
fieldnames for a while, sneaking around the protection by setting them up 
as column names in Shiraz dynamic tables, and then editing those tables. 
One use: column headings like § and @ that allow for compact and intuitive 
presentation, when the column data tends to be single-digit. But this is a 
superficial cheat (since these have been old-fashioned property-like 
fields).

More importantly, isn't this v5.2.0 step a path to more powerful 
(multi-dimensional) relational data, or at least virtual pivot-table 
behavior? 

Suppose a use-case that involves spread-sheet-like relation between 
tiddlers (rows) and fields (columns), where the field-names tend to have 
their own tiddlers (which until now we've named in the constrained way) 

Starting wth v5.2.0, can't field names can serve better as the intersection 
(cell) of these two dimensions? Values at the intersection should be more 
readily accessed via either axis of the table, so that what appears in 
Tiddler A, field F, also *could* be referenced easily within tiddler F 
(That is, F can be set up with filters to draw info from all tiddlers that 
use F as a field name). 

I imagine the intersectional-field-data housed remotely (on the other 
"axis") could be rendered like virtual fields (within a filter-condition 
ViewTemplate)... and it may even be possible to reach through and edit the 
remote intersection-field directly.

For true pivot-table purposes, a plugin could flag or help correct 
discrepancies between A's F-value and F's A-value, no?Obviously, this would 
have to be an optional feature, or one that hangs on some further 
condition, since some uses might call for A's F-value to differ from F's 
A-value -- especially on legacy projects built without intersectional power 
in mind.

I welcome corrections or clarifications from those who actually understand 
the guts of TW5!

-Springer
On Thursday, June 17, 2021 at 5:54:02 AM UTC-4 jeremy...@gmail.com wrote:

> One thing to bear in mind is that the core has always supported 
> unrestricted fieldnames for almost all operations. The primary thing that's 
> changing now is that the switch to the JSON store area allows us to 
> guarantee that arbitrary fieldnames will be respected over a 
> save-and-reload cycle. The secondary thing is the removal of the very weak 
> protections against creating fieldnames containing arbitrary characters.
>
> Perhaps there a relatively small number of usecases for complex 
> fieldnames, but some of those use cases are powerful and so seem important. 
> But even in the absence of important use cases, a very important benefit is 
> that unrestricted fieldnames make TiddlyWiki significantly simpler to 
> explain. Every little arbitrary restriction or caveat adds to the 
> conceptual load for people learning TiddlyWiki.
>
> For me, one of the most important consequences is that we can encode 
> variable name/value pairs as fields. For example, in the new publishing 
> framework that is under development we represent a publishing job as a 
> configuration tiddler that specifies the template to be used, the filter 
> identifying the tiddlers to be output, and a collection of variables to be 
> provided to the rendering. The variables are expressed as fields named 
> "var-foo", where "foo" is the name of the variable, and the field value is 
> the value for the variable.
>
> It's a simple and flexible approach that wouldn't be possible without 
> loosening the restrictions on field names.
>
> Best wishes
>
> Jeremy
>
> --
> Jeremy Ruston
> jer...@jermolene.com
> https://jermolene.com
>
> On 17 Jun 2021, at 10:42, Mohammad Rahmani  wrote:
>
> Like Mario, for me it is not clear what will be the benefit to have such 
> liberty in naming fields!
> I think Tiddlywiki is growing organically! Sometimes you need to see good 
> and consistent logic to be able to write better code to understand and 
> maintain!
> So, while I am not against the new feature in TW 5.2.0 but I really like 
> it, we are going toward a more consistent, easier to learn and easier to 
> maintain grammar and syntax!
>
>
>
> Best wishes
> Mohammad
>
>
> On Thu, Jun 17, 2021 at 11:27 AM PMario  wrote:
>
>> Let me be more specific eg:
>>
>> >So, the field values could be a relationship between the current tiddler 
>> and those other tiddlers. For example:
>> >
>> >title: Adam
>> >Barbara:mother
>> >Caesar:father
>> >David:friend
>>
>> You mentioned that having upper-case letters in the field names can help 
>> to solve the "relationship problem". .. 
>>
>> I ask: Where is the difference from a setting below and your suggestion? 
>>
>> title: adam
>> barbara: mother
>> caesar: father
>> david: friend
>>
>> There is no difference. The setting in the example has been there since 
>> v5.1.0 .. and the problem isn't solved. ... 
>> S

Re: [tw5] Re: Unrestricted field names... an implied use case

[Mohammad Rahmani]

Hi Jeremy,

Thank you for your clarification!

Best wishes
Mohammad

On Thu, Jun 17, 2021 at 2:23 PM Jeremy Ruston 
wrote:

> One thing to bear in mind is that the core has always supported
> unrestricted fieldnames for almost all operations. The primary thing that's
> changing now is that the switch to the JSON store area allows us to
> guarantee that arbitrary fieldnames will be respected over a
> save-and-reload cycle. The secondary thing is the removal of the very weak
> protections against creating fieldnames containing arbitrary characters.
>
> Perhaps there a relatively small number of usecases for complex
> fieldnames, but some of those use cases are powerful and so seem important.
> But even in the absence of important use cases, a very important benefit is
> that unrestricted fieldnames make TiddlyWiki significantly simpler to
> explain. Every little arbitrary restriction or caveat adds to the
> conceptual load for people learning TiddlyWiki.
>
> For me, one of the most important consequences is that we can encode
> variable name/value pairs as fields. For example, in the new publishing
> framework that is under development we represent a publishing job as a
> configuration tiddler that specifies the template to be used, the filter
> identifying the tiddlers to be output, and a collection of variables to be
> provided to the rendering. The variables are expressed as fields named
> "var-foo", where "foo" is the name of the variable, and the field value is
> the value for the variable.
>
> It's a simple and flexible approach that wouldn't be possible without
> loosening the restrictions on field names.
>
> Best wishes
>
> Jeremy
>
> --
> Jeremy Ruston
> jer...@jermolene.com
> https://jermolene.com
>
> On 17 Jun 2021, at 10:42, Mohammad Rahmani 
> wrote:
>
> Like Mario, for me it is not clear what will be the benefit to have such
> liberty in naming fields!
> I think Tiddlywiki is growing organically! Sometimes you need to see good
> and consistent logic to be able to write better code to understand and
> maintain!
> So, while I am not against the new feature in TW 5.2.0 but I really like
> it, we are going toward a more consistent, easier to learn and easier to
> maintain grammar and syntax!
>
>
>
> Best wishes
> Mohammad
>
>
> On Thu, Jun 17, 2021 at 11:27 AM PMario  wrote:
>
>> Let me be more specific eg:
>>
>> >So, the field values could be a relationship between the current tiddler
>> and those other tiddlers. For example:
>> >
>> >title: Adam
>> >Barbara:mother
>> >Caesar:father
>> >David:friend
>>
>> You mentioned that having upper-case letters in the field names can help
>> to solve the "relationship problem". ..
>>
>> I ask: Where is the difference from a setting below and your suggestion?
>>
>> title: adam
>> barbara: mother
>> caesar: father
>> david: friend
>>
>> There is no difference. The setting in the example has been there since
>> v5.1.0 .. and the problem isn't solved. ...
>> So as I wrote: Having more possibilities in the field names won't solve
>> anything. Sorry.
>>
>> -mario
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "TiddlyWiki" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to tiddlywiki+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/tiddlywiki/9663224c-7512-4bba-a424-decf876dc943n%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "TiddlyWiki" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to tiddlywiki+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/tiddlywiki/CAAV1gMDRxgAA8pZ1nnY56j34uTqw1ux8%2BX0gkqDTcSK-LPkX-g%40mail.gmail.com
> 
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "TiddlyWiki" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to tiddlywiki+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/tiddlywiki/FEB2B99E-6A23-42E8-A8B4-5B7A03670E83%40gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/CAAV1gMDqcpGJ3%3DQa%2B7ZSL%

Re: [tw5] Re: Unrestricted field names... an implied use case

[Jeremy Ruston]

One thing to bear in mind is that the core has always supported unrestricted 
fieldnames for almost all operations. The primary thing that's changing now is 
that the switch to the JSON store area allows us to guarantee that arbitrary 
fieldnames will be respected over a save-and-reload cycle. The secondary thing 
is the removal of the very weak protections against creating fieldnames 
containing arbitrary characters.

Perhaps there a relatively small number of usecases for complex fieldnames, but 
some of those use cases are powerful and so seem important. But even in the 
absence of important use cases, a very important benefit is that unrestricted 
fieldnames make TiddlyWiki significantly simpler to explain. Every little 
arbitrary restriction or caveat adds to the conceptual load for people learning 
TiddlyWiki.

For me, one of the most important consequences is that we can encode variable 
name/value pairs as fields. For example, in the new publishing framework that 
is under development we represent a publishing job as a configuration tiddler 
that specifies the template to be used, the filter identifying the tiddlers to 
be output, and a collection of variables to be provided to the rendering. The 
variables are expressed as fields named "var-foo", where "foo" is the name of 
the variable, and the field value is the value for the variable.

It's a simple and flexible approach that wouldn't be possible without loosening 
the restrictions on field names.

Best wishes

Jeremy

--
Jeremy Ruston
jer...@jermolene.com
https://jermolene.com

> On 17 Jun 2021, at 10:42, Mohammad Rahmani  wrote:
> 
> Like Mario, for me it is not clear what will be the benefit to have such 
> liberty in naming fields!
> I think Tiddlywiki is growing organically! Sometimes you need to see good and 
> consistent logic to be able to write better code to understand and maintain!
> So, while I am not against the new feature in TW 5.2.0 but I really like it, 
> we are going toward a more consistent, easier to learn and easier to maintain 
> grammar and syntax!
> 
> 
> 
> Best wishes
> Mohammad
> 
> 
>> On Thu, Jun 17, 2021 at 11:27 AM PMario  wrote:
>> Let me be more specific eg:
>> 
>> >So, the field values could be a relationship between the current tiddler 
>> >and those other tiddlers. For example:
>> >
>> >title: Adam
>> >Barbara:mother
>> >Caesar:father
>> >David:friend
>> 
>> You mentioned that having upper-case letters in the field names can help to 
>> solve the "relationship problem". .. 
>> 
>> I ask: Where is the difference from a setting below and your suggestion? 
>> 
>> title: adam
>> barbara: mother
>> caesar: father
>> david: friend
>> 
>> There is no difference. The setting in the example has been there since 
>> v5.1.0 .. and the problem isn't solved. ... 
>> So as I wrote: Having more possibilities in the field names won't solve 
>> anything. Sorry.
>> 
>> -mario
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "TiddlyWiki" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to tiddlywiki+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/tiddlywiki/9663224c-7512-4bba-a424-decf876dc943n%40googlegroups.com.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "TiddlyWiki" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to tiddlywiki+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/tiddlywiki/CAAV1gMDRxgAA8pZ1nnY56j34uTqw1ux8%2BX0gkqDTcSK-LPkX-g%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/FEB2B99E-6A23-42E8-A8B4-5B7A03670E83%40gmail.com.

Re: [tw5] Re: Unrestricted field names... an implied use case

[Mohammad Rahmani]

Like Mario, for me it is not clear what will be the benefit to have such
liberty in naming fields!
I think Tiddlywiki is growing organically! Sometimes you need to see good
and consistent logic to be able to write better code to understand and
maintain!
So, while I am not against the new feature in TW 5.2.0 but I really like
it, we are going toward a more consistent, easier to learn and easier to
maintain grammar and syntax!



Best wishes
Mohammad


On Thu, Jun 17, 2021 at 11:27 AM PMario  wrote:

> Let me be more specific eg:
>
> >So, the field values could be a relationship between the current tiddler
> and those other tiddlers. For example:
> >
> >title: Adam
> >Barbara:mother
> >Caesar:father
> >David:friend
>
> You mentioned that having upper-case letters in the field names can help
> to solve the "relationship problem". ..
>
> I ask: Where is the difference from a setting below and your suggestion?
>
> title: adam
> barbara: mother
> caesar: father
> david: friend
>
> There is no difference. The setting in the example has been there since
> v5.1.0 .. and the problem isn't solved. ...
> So as I wrote: Having more possibilities in the field names won't solve
> anything. Sorry.
>
> -mario
>
> --
> You received this message because you are subscribed to the Google Groups
> "TiddlyWiki" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to tiddlywiki+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/tiddlywiki/9663224c-7512-4bba-a424-decf876dc943n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/CAAV1gMDRxgAA8pZ1nnY56j34uTqw1ux8%2BX0gkqDTcSK-LPkX-g%40mail.gmail.com.