[discussion] How will you be taking advantage of the removal of character restrictions from field names?

[Si]

As you are probably aware, the next release of TiddlyWiki will remove the current restriction on characters for field names (https://groups.google.com/g/tiddlywiki/c/kF-OGmkyFfo/m/dN-P0KRVBQAJ).

I feel like this adds a lot of potential for new workflows, but don't have any particular ideas myself.

So I'm curious if there are users out there who plan to adapt their workflow, or introduce new workflows, as a result of this change?

Do you plan to change the way that you name or use fields? If so how?

[TW Tones]

Si,

Good Question: I will have a go, but I expect time will help.

• One important note is I still intend to use the original limited field names as I currently do, when I use fields that use the extended naming it will be to make use of the possibilities. 
  • Of course this is needed for backward compatibility
• Interestingly I think, one way to make use of these freedoms is to be able to develop new constraints, hopefully this will be clear later in this reply.
• You can see that in simply replying to your question, I have being able to explore the possibilities further than I have so far.
• Handled well it may prove to be revolutionary.
• I think there is an argument if not handled well some tiddlywiki solutions could become unreadable
• Perhaps this could be used for some "security by obscurity" eg encrypted fieldnames

Tiddler names as fieldnames

Possibly the most meaningful possibility is to create fieldnames using a tiddler name, then being able to use the value of the field to store information about the relationship between the two tiddlers

Eg lest say we have two tiddlers Alice and Bob lets say Alice is given a field "Bob" containing the value "husband".

• Not only do we name the tiddler Bob to which Alice has a relationship, but the nature of that relationship
• But it is simple to search all tiddlers containing a field called "bob" to find what other tiddlers have a relationship with Bob
  • You can see here the the relationship may be better named "spouse" and you derive husband and wife from this.
• One thing you may notice is what if I was using the tiddler name as fieldnames for other purposes, lets say Alice and Bob are both members of the book club so this is where I am likely to use the fieldnames differently.

Compound fieldnames

The freedom to use many different characters in fieldnames allows us to make use of compound fieldnames, which I explain here, but you will see that todo this successfully we have to in some ways need to reintroduce constraints, or naming standards. 

• For example if I apply an informal constraint on tiddler names that I will not use colon in the tiddler title.
• I can then use ":" to delineate parts of fieldnames so to extend the above example
  • "relationship: spouse" value="Bob" 
  • or even " relationship: spouse: Bob" value="date of marriage"
• I can then search for fieldnames based on a prefix "relationship" where we split on ":" then last[] will find the tiddlername "Bob"
• I can see how since : is in use in URLS, that may form titles It may be better using a character that is not on a keyboard.

Shorthand fieldnames

Given fieldnames can use unicode symbols and other character sets rather than use the simple standards I see value in using these as fieldnames

• eg  ☎ phone,  📧 email address, or mobile  📱
• This means
  • the meaning of the field is part of the fieldname
  • only one character is required
• We can also use this to introduce custom fields with the same quality.
  • 📧 = preferred email address
    
  • "📧 Personal"
    
  • "📧 Business"

Field types

You can see in the above example the prefix represents an email address. This allows you to determine the value of that field needs to be a valid email address. So you can effectively use this character to determine the type of the field and determine how to display or edit any "email address".

• We could use special symbols but naming standards can also add meaning to a fieldname; for example all fields ending with ":link" the prefix would be a pretty link, the value the actual link
  • eg fieldnamed "tiddlywiki.com :link" value="https://tiddlywiki.com" 
• This could be important to define fields that are textareas or rich text 🖺

Field Lists

You could do this in the current naming standards or within fields who's values are a list but this would be easier to read/edit in some cases. For example imagine a menu-tiddler with the following fieldnames

• ":menu-item :Top :01" value=<a target="_top"...
• ":menu-item :middle :02"  value=[[Home]]
  

You can see in the above because the fieldname includes the pretty link Top and middle that they will be unique but the addition of the number can guarantee this and store the order.

Guaranteed Plugin in or macro fieldnames

I for one write a lot of macros and so use the names space of $:/PSaT/.... for my tiddler titles. We can now also uniquify fieldnames for example I could prefix all fields used by a particular string that represents me as the author eg PSaT.

In closing

I am sure more possibilities will arise than explored in this reply, however I think it highlights the value in using such extended fieldnames for purpose, and that the development of new naming standards applied on top of such freedoms by the designer is likely to bare more fruit than "las a faire" naming. It raises the need for a suit of tools to assist the designer in making use of these features from Editor toolbar buttons, advanced field lookups, tiddler to fieldname tool, to character selection tools like https://qaz.wtf/u/convert.cgi but built into tiddlywiki. Or https://unicode-table.com/en/ to use and enter symbols.

It would be interesting to discover what other solutions make use of liberated fieldnames and what have they done!

Regards

Tones

[TW Tones]

Si/Folks,

With just a few minutes research on unrestricted fieldnames another revolutionary possibility becomes apparent. Compound fields (not fieldnames).

The value follows the semi-colon : in this example

address: title name add1 add2 city state post-code

address title: Mr

address name:  Anthony Muscio
address add1: NFP

address add2: NFP

address city: Kareela

address state: NSW

address post-code: 2232

This would allow you to programmatically bring all address fields together as an "address", you could add a new element for a one off special case or use this to present the form to enter the address.

Regards

Tones