Designer Question: Can we pollute the fieldname space like we can the tagname space?

[TonyM]

Folks,

Background

I avoid polluting the tag name space by using fields whereever possible rather than tags, including alternative tag fields. I retain my tagging options for ad hoc relationships.

I am only now becoming concerned that a pile of solutions I have, for which I have developed my own fieldname standards, may be polluting the fieldname space. That is I define so many fields, it could perhaps confuse users or designers.

• I could make use of the core method to hide fields to reduce this impact
• I could use a prefix for my various solutions fields, 
• But I think this is ugly, because you can make nice filters with english words
  eg fieldname[fieldvalue] or show-details[yes] rather than _show-details[yes] or psat-show-details[yes]
• but many fieldnames set a standard I use for a given fieldname and I want them standardised.

Only recently I discovered a way to include additional information within the text fields that are not visible so they can even replace fields. 

This method also provides a method to use the name multiple names eg:

<!--
Reference: Some reference info
Reference: Some more reference info
-->

A Small set of custom filters and macros help work with this.

Question?

So since I now have an additional method should I reduce my use of additional fields and make use of my discovery to reduce polluting the fieldname space?

I would appreciate your view

Note: A Common answer in tiddlywiki is don't bother, use as many as you want and if you get into trouble change it, does that apply here?

Regards

TonyM

[PMario]

On Friday, May 15, 2020 at 5:17:29 AM UTC+2, TonyM wrote:

...

Note: A Common answer in tiddlywiki is don't bother, use as many as you want and if you get into trouble change it, does that apply here?

Yes. :))

For your private wikis you can do what ever you want.

--------------------

For plugins the point is:

If you want to standardize field-names, without prefixes and include them into the TW core, you have to have really, really, really good arguments. Because names that the core uses can't be used ever again by users, for a different purpose.

That's why the core itself tries very hard, to avoid name collisions. eg: Have a look at the system tag: $:/tags/Stylesheet for a sytem-tags. It would have been easy to use $:/Stylesheet or Stylesheet. But that didn't happen. The main reason is, that it is very likely, that "new users" want to use them for their own use-cases.

So Jeremy had to find a tag name, that is self explaining enough to be useful _and_ that gets out of the way for end-users.

If you are a plugin-author .. you are _no_ end-user anymore. Publishing plugins comes with the responsibility to "go out of the users way" ... as good as possible.

Using a field-name like: _show-details or show-details is definitely limiting the possibilities for your users. So it's good, that you think about it!

Especially as we already promoted _field-name with a special meaning as a "private" name. So everything which is prefixed with _ should be treated as "user private" and not "plugin private".

The advantage of _xxx-name or $:/_xxxx-name for system tiddlers is, that it is automatically sorted at the beginning of sorted lists. ... This behaviour should be reserved for end-users, to make their live easier. IMO plugins shouldn't take this away.

BUT as always: This is "just a convention". You can do whatever you want, and see, how it works out!

Plugin tiddlers do have a namespace like: $:/plugin/<authorName>/<pluginName>/as/complex/as/you/like/it

Code that comes with plugins should follow this convention because it is "best practice".

------------------

If you thought about the things listed above, _and_ there is no other way to make a field-name useful then use it, without any pre-fixes! ... May be a postfix?

Eg: I did use the field name: aliases for my uni-link plugin. It is a space separated list of titles. Anything else doesn't make much sense and imo it is specific enough, that it could also be used by other plugins, that do the same thing, without a naming and meaning problem.

I also used the field name: subtitle in contrast to the core caption field. ... I consider aliases and subtitle as "de facto" standards now. .. BUT there is the risk to cause naming collisions in the future.

That's why you should really think carefully, until you try to establish a new "de facto" standard! .. Other plugin authors and users will have to accept them.

If you use xxx-yyy  field names, imo you should not hide them in the editor. The risk is too high, that users overwrite them and your plugin will probably cause really hard to find side effects. If users don't know, that they have overwritten something, they have no chance to tell you, if there is an issue.

If you try to establish many plugin-related fields. I personally would go with a postfix. show-info.psat ... So I can use show-info.wl ... OR we both agree on the behaviour of how show-info should work ;)

just some thoughts.

have fun!

mario

[PMario]

On Friday, May 15, 2020 at 2:18:21 PM UTC+2, PMario wrote:

If you try to establish many plugin-related fields. I personally would go with a postfix. show-info.psat ... So I can use show-info.wl ... OR we both agree on the behaviour of how show-info should work ;)

As i wrote this, I had an idea. ... What if plugin authors agree on a defined behaviour for new fields. This would allow us to use the same field name with multiple plugins.

This may lead to "total confusion" but imo it's worth some thoughts. eg:

field name: show-info

values: yes.psat no.wl

So my filter code could be: [contains:show-info[no.wl]] and your [contains:show-info[yes.psat]]

This can only work, if every plugin-author would work that way from the beginning. .. It wouldn't be possible to test for "empty value" anymore, because an other plugin would have a value in the field. That wouldn't be a problem for me personally, but may be for others.

Adding new values can be done with: append and removing a value can be done with: remove. ... A _new_ toggle listops may be a convenience function.

The above would only make sense for "yes / no" like fields.

just some thoughts

mario

[HansWobbe]

@pmario:

Thank you very much for posting this information.  It's an excellent and timely summary of material that I should be thinking about as I become a bit more active. in this community. ( _HwWvW )

Cheers,

Hans ( z_tag )

[Mat]

I avoid polluting the tag name space by using fields whereever possible rather than tags, including alternative tag fields. I retain my tagging options for ad hoc relationships.

About how the system ought to work, you may want to look up this request: https://github.com/Jermolene/TiddlyWiki5/issues/1324

Do comment or like if you have opinions.

<:-)
 

[TonyM]

 Mario,

Thanks for sharing your expertise on this. I have a need for a subtly different approach, because I am thinking of fields I may use in solutions I deliver. Solutions intended for common use. For example a journal-date field with a time stamp so there is no need to parse the "pretty title", or a tool that displays "descriptions" when they exist in a verbose mode. 

I can keep this all in my wikis, but I would like to share my work to save others time.

So the OT was can I pollute the fieldname space, You said yes, and I should consider moving some capabilities away from tags and fields is appropriate.

Here is what has led me to this whole question;

I have built a development environment that allows me to define and handle objects and fields, I have simplified this with a seperate set of reusable field types, and they respond to a different modes the wiki is in. I now have a library of field and field type definitions for a lot of common fields, from email addresses to reference links and source urls. I have secured the meaning of these fields by using them on tiddlers only with an object-type field but they are freely available to use anywhere and come with their own display/report/table and editing tools, including special modes such as given a year number how many years old is it.

It in this open source shared environment I would like to build the resources to make better use of fields for every one.

If installed on an empty.html they should give plain and simple fieldnames with meaning by their name and not cluttered with prefixes or suffixes. I believe this should not cause conflicts with plugins and if one field did you can redefine it, create a new one.

Another example is on $:/config/tiddlers I can add a field called config-values containing the possible values including a filter then build a solutions that works on all config tiddlers, buttons, selects and opening the tiddler itself. It would be a defacto standard for me and anyone that uses it, but it would not make sense to add .psat, especially to the values.

My feeling is if field names are well chosen, there will be few overlaps, as long as their use is scoped eg; on tiddlers with $:/config/ prefix the config-values may exist. If authors could register what the names of the fields are and what kind of content they hold others can view the registry and decide their own or to reuse a name. eg; a Keywords field, would presumably hold only words not tiddler titles?, a system-caption would be an alternate name for a system tiddler like a caption that will appear in standard search such as  link to 

$:/Manager would be named "Tiddler Manager" in search results.

These solutions almost depend on using the appropriately named fields.

Regards

Tony