How could system-fields look like with 5.2.x

[pmario]

Inspired by: #5804

Latest example: #5805 (comment)

We do have system-tiddlers that start with $:/ which makes them almost invisible for ordinary users. The same thing could be true for system-fields ... BUT ... There needs to be an additional property for those fields.

We always had problems with some special system-fields: created, modified, tags .. those fields do have a "special handling" in the core. .. They use "setters" and "getters" to convert them on the fly. Such a behaviour would be nice to have for "user fields" too.

Proposed system-fields spec

(edited 18.6. changed $:/ to #/ to reduce confusion. see: #5805 (comment))

• They start with #/
  • The : char may be problematic. see: [BUG] Tiddlers with multi-line fields can be incorrectly exported as .tid files #5809 ... (22.6) removed it from all posts
• They are hidden from default search
• They are hidden in the EditTemplate
  • There should be a small unobtrusive indicator, that "hidden fields" exist
• They MUST have an <type> snippet as the first element iin the namespace: #/<type>/ eg: #/date/
• They do have an <author> snippet in the namespace .. eg: #/date/<author>/
• If they are used in plugins the do have <plugin> snippet in the name .. eg: #/date/wikilabs/<plugin>/xxx
• If they are connected to a visible user filed they may look like #/user/<type>/<name of the field>
  • user-fields, that have a related system-field should have an unobtrusive marker
• If they need a multiline editor #/user/multiline/<name of field> or #/multiline/<author>/myDescription. So the myDescription field would automatically show a multi line editor.

Possible Types

• user ... the field will create a visible "user-field" (22.6 changed)
• _ ... user ... a convenience type, to create shorter names (22.6 changed)
• string ... string (22.6 changed)
• date ... similar to modified
• tag ... similar to the tags field
• list ... similar to the list field
• type ... MIME type .. So an automatic "dropdown" can be shown (22.6 replaced by mime)
• color ... A color selector can be shown
• mime ... A field that can be defined by an official mime-type (22.6 new) see: How could system-fields look like with 5.2.x #5805 (comment)
• multiline ... shows a multiline edit field .. (22.6 replaced by mime)
• relations ... I don't know how this will look like .. But may be multiline with a key: value pair ...
• json ... A multiline field, that contains a JSON structure. ... IMO this may be nestable (22.6 replaced by mime)

(remark 22.6) With the MIME-type idea, it may be possible to reduce or get rid of this configurations. -- Will need to be explored

Needed

• IMO it's just a new convention, that will allow us to improve field flexibility
• There needs to be a possibility to define such "system-fields" globally.
• There needs to be a UI that will allow us to find all system-fields, since they are invisible for the standard search
• AdvancedSearch probably needs a new tab .. may be

[Jermolene]

Hi @pmario

• I'm concerned that making field names look like system tiddler titles will add a lot of unnecessary confusion. Right now if I see $:/foo/bar it is fairly safe to assume that it is a tiddler title. It would be a shame to add ambiguity. So I think it would be better to use a different prefix and separator. Perhaps underscores to match the existing _canonical_uri field
• I don't understand why it is useful to have fields that are hidden from end users. If a plugin needs to add metadata to a user-created tiddler then I'd normally use a separate configuration tiddler
• Having fields that a user can't see would seem to invite confusion. For example, if updating such fields also updates the "modified" field then users will wonder why tiddlers with no apparent changes have moved to the top of the "Recent tab". But, conversely, if we don't update the "modified" field then we'd have introduced the phenomenon of tiddlers that change without them moving in the "Recent" tab

Overall, I would take these proposals as interesting starting points for establishing conventions for the use of field names, but I don't think we're ready to bake those conventions into the core

[kookma]

I am very much for simple and more understandable field names! I don't think TW needs to have such complexity in filed naming etc. So I highly support Jeremy with his above explanation!

Please note: field names normally used for scripting, transclusion (e.g mostly [not always] of programming use case) so it would suffice to have filed name in lowercase and I think few usecases needs special chars, upper case, etc.

[pmario]

I don't understand why it is useful to have fields that are hidden from end users. If a plugin needs to add metadata to a user-created tiddler then I'd normally use a separate configuration tiddler

modified, created, creator, modifier are hidden and nobody complains or is confused about that.

Overall, I would take these proposals as interesting starting points for establishing conventions for the use of field names, but I don't think we're ready to bake those conventions into the core

That's why it's under "Discussion" and not an issue.

[pmario]

@Jermolene wrote

I'm concerned that making field names look like system tiddler titles will add a lot of unnecessary confusion. Right now if I see $:/foo/bar it is fairly safe to assume that it is a tiddler title. It would be a shame to add ambiguity. So I think it would be better to use a different prefix and separator. Perhaps underscores to match the existing _canonical_uri field

That's fair. ... IMO underscores are not really good separators for a namespace.

What about §:/ or #:/ as a prefix §:/foo/bar -- $:/foo/bar -- #:/foo/bar ... I think the later has the biggest visual difference

[pmario]

The field named: color automatically gets a color-picker ... Why does the field: myColour get no color-picker?

IMO #/user/color/myColour value green would easily solve the problem. green would be the default colour, if the user would create the field: myColour ... The system field would be invisible and the myColour field would get a clickable visual hint, that it has a configuration field.

With the hint, I think there wouldn't be any confusion

[pmario]

Possible workflow for a "multiline input area"

• I do create a field name: #/user/multiline/teaser value:rows: 4
• Click the [add]-button
• A field named: teaser will be automatically created and a text-editor with 4 lines will be shown.

I think that would be cool!

[pmario]

It would be cool if #/user/multiline/teaser would support all parameters from https://tiddlywiki.com/#EditTextWidget

If system-field parameters look like widget parameters, they should be easy to write and parse.

A non working .tid could look like so:

title: my tiddler
#/user/multiline/teaser: rows="4" minHeight="3em"
tags: a b c 
teaser: -=-=-=-=-                         <- end-marker config for the parser
line 1
line 2
line 3
-=-=-=-=-                                     <- end-marker
some text

Thinking a bit further. What if the multiline field would look like this:

#/user/multiline/teaser: rows="4" minHeight="3em" tiddler="somewhere else"

Would this have use-case?! Would the "relink plugin" be able to handle this? Edit: 2022-12-05 (No tiddlers should be "self contained")

[pmario]

@Jermolene wrote

Having fields that a user can't see would seem to invite confusion. For example, if updating such fields also updates the "modified" field then users will wonder why tiddlers with no apparent changes have moved to the top of the "Recent tab". But, conversely, if we don't update the "modified" field then we'd have introduced the phenomenon of tiddlers that change without them moving in the "Recent" tab

If I change a field something, which is dynamically updated, but not shown in any UI context it will also change the modified field. ... I haven't seen any complains about fields that work that way. .. So I think it won't be a problem with #/system-fields

[pmario]

@Jermolene What do you think about multiline fields like this:

title: my tiddler
#/user/multiline/teaser: rows="4" minHeight="3em"
tags: a b c 
teaser: -=-=-=-=-                         <- end-marker config for the parser
line 1
line 2
line 3
-=-=-=-=-                                 <- end-marker
some text

[pmario]

From the system-field we know, that teaser is multiline. The end-marker can a dynamic string eg: -=-=-=-=-
I think parsing this should be straight forward.

[AnthonyMuscio]

Mario,

Would it be too much to actually name the text field text: and allow it to be followed by a mime type or other format eg

title: my tiddler
tags: a b c
text:text/vnd.tiddlywiki
Multiline text
data:application/x-tiddler-dictionary
data dictionary text?
journal-date:date-time

The actual format or mime types need not be stored in the tiddler, only obtained before exporting. Keeping in mind this will be different in the JSON store.

The idea is the type becomes associated with the field not the tiddler as a whole, which really only means the text field anyway.

[pmario]

That's a very interesting idea. I'll follow it

[AnthonyMuscio]

All,

I would like to support what Mario is trying to achieve here there are two key reasons we need some change which is appropriate at the same time as the field namespace expands.

Another is the possibility that the JSON tiddler structure that allows these field extensions also opens up the use of editing the current tiddlers and their fields through the view template without the old focus problem. I believe this will stimulate the development of interactive forms and thus the demand for fields to have better handling, ie become first class citizens (like tags)

• Currently there is no open hacks to duplicate the behaviour of created, modified and color fields (lets call these magic fields), ie provide edit and display of fields with a known types.
• I would extend Mario's ideas to have field definition tiddlers (as we can have tag tiddlers) and for fields to be assigned field-types (custom AND/OR mime type)
• Until the fields editor can detect and handle multi-line fields there is a reason to hide a field from the editor (even if another field editor is reintroduced via $:/tags/EditTemplate)
• If the edit template allowed fields to be arranged, sorted, be given definitions , hidden etc.. the edit template could respond better to the use of custom fields. However other than multi-line fields I believe the edit view should remain the designers opportunity to edit anything, where form handling from the view template should be the designers responsibility and full control.
• There is value in being able to set a global and tiddler mode to alter the way thwe user interacts with the wiki eg edit, view and Update tiddler modes, where update allows a form to be used to edit the tiddler and makes use of field definitions and field types to provide the appropriate field editor.
• Rename local-viewtemplate.json.txt to import my local-view template that has a multi-line field on tiddlers. Add the field local-viewtemplate on a tiddler to see it. Then add content to display on view template.

Mario,

Perhaps rather than defining the field as a system field using a name prefix perhaps we externalise it to a tiddler or data tiddler. This may be necessary any what to support field definition and field types. We can then flag the field definition tiddler as system or hide etc...

I have done this many times so can demonstrate this in more detail. It keeps the solution much more open. Separate field types allows a set of generic display and edit features to be developed for reuse in many field definitions. eg one field type for date applied to many date fields. Field definitions and types would allow the sharing of these for import without insisting on a wiki edition that supports a given field. Perhaps ultimately some field definitions would move to the core (or replace the existing magic fields) . Such definitions and field types can be cloned by the designer to extend or customise new fields.

I think this solution also more closely resembles other systems and is not yet another TiddlyWiki quirky implementation, of a common or garden element such as fields.

Regards
Tony

[pmario]

I would extend Mario's ideas to have field definition tiddlers (as we can have tag tiddlers) and for fields to be assigned field-types (custom AND/OR mime type)

I want tiddlers to be "self contained". So if possible, the info shouldn't be split into 2 tiddlers, because that causes a sync problem

[pmario]

If the edit template allowed fields to be arranged, sorted, be given definitions , hidden etc.. the edit template could respond better to the use of custom fields. However other than multi-line fields I believe the edit view should remain the designers opportunity to edit anything, where form handling from the view template should be the designers responsibility and full control.

Having better control of the field types, will allow us to create an EditTemplate, that looks like a ViewTemplate. ... So we can go away with all the ViewTemplates hacks, that only cause problems. .. If I need to edit something I should use an EditTemplate...
This EditTemplate can be adjusted on a per tiddler basis.

[pmario]

Perhaps rather than defining the field as a system field using a name prefix perhaps we externalise it to a tiddler or data tiddler. This may be necessary any what to support field definition and field types. We can then flag the field definition tiddler as system or hide etc...

As I wrote. I'd like to have self-contained tiddlers including all the meta-data

[AnthonyMuscio]

Mario,

I think that is a good approach yet a field definition is something that sensibly applies wiki wide. An example is the color field, it is not defined in the tiddler but elsewhere in the wiki. What would be ideal is a fall back to a simple editor as we currently do, if the definition is not present, or at least a single or multi-line edit. If both an assignable mime or format type exists use it. This allows extensibility and fine tuning at the same time.

A simple example of extending field definitions and types beyond that which we would store in each tiddler may be a field definition whose value can be selected as a result of a filter or even a MRU most recently used values list.

Tony

[AnthonyMuscio]

The exception may be for multi-line fields that can be appropriately defined with A type or mime type in the field, ensuring transferability.

My concern would be having the metadata always in a field within a tiddler giving rise to redundant information through out the wiki. A compromise with a fall back would be the best method. Perhaps with an export method that includes the metadata if desired.

Tony

[pmario]

New possible .tid format

title: my tiddler
#/user/multiline/teaser: rows="4" minHeight="3em"
tags: a b c 
teaser: MIME-TYPE  |  -=-=-=-=-                     <- end-marker config for the parser
line 1
line 2
line 3
-=-=-=-=-                                     <- end-marker

• Since mime-type naming specification doesn't allow the "pipe" | character in the name, it is safe to use it as a separator for the "end-marker"
• Since the : character is problematic in field names I did remove it from all posts

[AnthonyMuscio]

Mario,

Some creative speculation.

It seems however we come to this type of approach, it seems having a "nonmeclature" that allows us to hide additional content in the tiddler for a given tiddler/fieldname would make sense. Basically an escape sequence and within the escaped information we can add something such as a mime type or format tiddler (Containing info about how to display/edit, export etc..)

The idea is if we have to look at modifying the rules around tiddlers lets do so with a view to a generic feature, then build a specific instance of using that (field types).

I suppose what I am proposing is a generic solution to adding additional information to a field defined in a tiddler, and saved in the tiddler that although saved with the tiddler is ignored unless a process exists to handle the content. then one instance of this use could be a "mime-type:text/vnd.tiddlywiki" or "field-type:typename". This possibly becomes easier with tiddlers stored as JSON?

I suppose we could also say the new tiddler format permits the inclusion of metadata against any field. A special field for whole of tiddler metadata would be nice as well. Arguably a tiddler could contain its own metadata naming the default export template or format it can save as. ie tiddlers could be designed to export as other file formats and types.

With the above in mind, could it be as simple as using comments within the content of the field? , then when transcluding or editing don't show the comments?

Or
fieldname<!-- mime-type:mime-type:text/vnd.tiddlywik export:command-file.cmd -->: value

Tony

[AnthonyMuscio]

In the above example if we can extract the mime-type from fieldname, or present it as a virtual field/value, all the better.

[AnthonyMuscio]

As I also suggested before but for clarity re local global/default.

Lets say I had a field called "data:. I may wish to create a tiddler containing something like
data:<!-- mime-type:application/json --> however I want to be able to define the "data" field in my wiki as having the mime-type:application/json basically a global field definition is possible, but a local override is also possible. So the data field may be application/json but in a specific tiddler it may be text/plain

Tony

[pmario]

A new try with mime-types and different elements.

#/mime/#icon: width="100px;" height="50px;"
#/icon: image/png | === end-image                                  <- This is a system-field
"data:image/png;base64,iVBORw0KGgoAA....."
=== end-image
title: my tiddler
#/_/mime/teaser: rows="4" minHeight="3em"
#/_/mime/wikitext: rows="10" minHeight="3em"
tags: a b c 
teaser: text/plain  | -=-=-=-=-                         <- end-marker config for the parser
line 1
line 2
line 3
-=-=-=-=-                                     <- end-marker
wikitext: text/vnd.tiddlywiki  | -=-=-=-=-                         <- end-marker config for the parser
line 1
line 2
line 3
-=-=-=-=-                                                                 <- end-marker
#/_/mime/date: <info for a date-picker to specify>        <- jCal format https://datatracker.ietf.org/doc/html/rfc7265#section-3.6.5
date: application/calendar+json | -=-=-=-=-
["dtstart", {}, "date-time", "2012-10-17T12:00:00"],
["dtstamp", {}, "date-time", "2012-10-17T12:00:00Z"],
["dtend",
    { "tzid": "Europe/Berlin" },
    "date-time",
    "2011-10-17T13:00:00"
]
-=-=-=-=-

some text

[AnthonyMuscio]

Mario et al,

Ok this is "out of left field".

Another approach to "system fieldnames" and "tiddler titles for that matter" is the use of unicode. If a field is named with a Unicode character or an alternate Alphanumeric set, without help, people can not enter the name in the search box, so they remain hidden from the basic search however with a unicode font that displays the name it remains readable.

To support such a method we could do with an in wiki Unicode keyboard.

Of course we need to consider the implications of this, but we also need to take account of this possibility with the new expanded field naming.

Perhaps we could have a single Unicode character acting as a Synonym for $:/ when used as a prefix to a field OR tiddler name?
Eg the fullwidth "Ｓ" or ℐ for fields.

I have played extensively with Unicode, and tiddlywiki is quite accommodating with tiddler titles but currently not with fieldnames.

Tony

[simonbaird]

On the topic of how to encode multi-line values, could we use an existing standard instead inventing our own? How about YAML?

[saqimtiaz]

YAML and the use of it as frontmatter in markdown has been on my mind for multiline support in .tid files. I haven't had the chance to look into how well it handles longer context though.

[pmario]

console.log(require('yaml').stringify({"text":"Some content", "title":"MyTiddler", "a multi-line field":"this\nthat"}))

If I paste this into the browser console, I get "require not defined" ...

[pmario]

text: Some content
title: MyTiddler
a multi-line field: |-
  this
  that

That's nice, but there isn't enough information for the UI to know how to display the input area in the EditTemplate.
There isn't any information about the render-type. .. Should it be wikitext or plain-text?

IMO these elements need to be user-defineable

TW doesn't have a YAML parser atm. We would need to bind a 3rd party dependency into the core.

---

The following code has all the info to tells the parser and the UI how to create an input area for the field. The only new thing is that I need to tell the parser where the text-block ends. eg: -=-=-=-=-

#/_/mime/wikitext: rows="10" minHeight="3em" _endString="-=-=-=-=-"
wikitext: text/vnd.tiddlywiki 
line 1
line 2
line 3
-=-=-=-=- 

[pmario]

The code may also look like this. Depending on what's easier to implement.

#/_/mime/wikitext: rows="10" minHeight="3em" 
wikitext: text/vnd.tiddlywiki | -=-=-=-=-
line 1
line 2
line 3
-=-=-=-=- 

[ght]

YAML and the use of it as frontmatter in markdown has been on my mind for multiline support in .tid files.

TW doesn't have a YAML parser atm. We would need to bind a 3rd party dependency into the core.

I strongly urge you to consider alternatives first, YAML has a bunch of problems, see https://noyaml.com/.

[pmario]

On the topic of how to encode multi-line values, could we use an existing standard instead inventing our own? How about YAML?

The only thing which is new in my proposal is the "start" and the "end" definition of a multiline field. Everything else is already part of the TW core parser primitives. ..

[simonbaird]

I agree the the overhead of adding js-yaml to the core is probably a blocker for using YAML. But I just want to mention the idea of using something standards based instead of "special for TiddlyWiki" in case it leads anywhere.

One more comment: it seems weird to include the width and height of a text area in the tid file. Could there be some other way to associate a specific UI template with particular field name?

[pmario]

One more comment: it seems weird to include the width and height of a text area in the tid file. Could there be some other way to associate a specific UI template with particular field name?

If it should be "self-contained" the info has to be part of the tiddler. ... On the other hand, there may be the need for "global" field definitions .. I didn't think about that in detail yet, but there may be 1 "meta" tiddler per global field

The disadvantage with 2 tiddlers that belong together and don't work without each other is all kind of syncing problems. I would like to avoid that

[AnthonyMuscio]

Mario,

I understand your desire to make tiddlers stand alone, however this is only necessary in some cases. An example may be my tiddlers may be todo tiddlers used inside Projectify,, now I may add a sunset-date field to a tiddler - lets imagine now there is a "field tiddler" called "sunset-date" and a field-type tiddler called date. If I drag and drop this tiddler to my other wiki I may not need the field and field type tiddlers because they are already their.

My experience tells me that we could call a field almost anything, but the number of field-type tiddlers can somewhat be finite. I envisage us collecting a set of field-type tiddlers into a plugin and sharing them so if you drag tiddlers with custom fields you can then assign the desired type to each field according to the needs in the destination.

Alternatively we can make a special bundler plugin that takes the tiddlers defined in a filter and sources all their field definitions and field-types in use and adds them to the package.

I can see that there may be a $:/field/description tiddler which has a field-type field of text-80, for which their is a tiddler "$:/field-type/text-80", which indicates its visible in the edit mode (not hiddent visibility), and that is uses {{!!fieldname}} to display in view and
<$edit-text field="description" size=80 placeholder="provide description"/> to edit.

So any field will try and find its field tiddler using the default naming standard (prefix $:/field/) UNLESS an alternate is named in the tiddlers hidden area, or as proposed there is a mime type.

I will try and deliver a working example.

Tones

[AnthonyMuscio]

Post script, we could also have wild card field definitions

• suffix[-link]]?
• menu-item-n
  Tones

[Jermolene]

@pmario's proposal in the OP is an attempt to resolve a long-standing niggle with the way the TW5 core gives special behaviour to certain fields that is hardcoded and can't easily be extended to user defined fields.

The core of the proposal is to use much longer multipart field names that embed type information and other metadata. It's an interesting approach, and it's helpful that you've followed it through with a lot of detail. Generally, I like this kind of speculative design thinking and the discussion it engenders.

In this case, I think the proposal ends up being overly complex because it essentially turns fields into tiddlers: as soon as we add metadata like a "type" to a field, it just becomes a mini-tiddler. Having two levels of the design with the same general features leads to a lot of complexity.

I think that as far as the core is concerned, fields should just be strings. At the application level, the kind of conventions you outline might be useful, but those usages need to evolve in the wild.

There are a number of other topics covered here, too. If we want to discuss these further, please can we do so in a separate thread/issue

• @pmario brings up a proposal for extending the .tid file format to allow for multiline field values. I do think we should do this, but I don't think it's a priority for v5.2.0. I would also note that the existing behaviour of the .tid parser is to ignore lines starting with a colon, which I think makes a promising point of extension to retain backwards compatibility (ie, lines starting with a colon could be interpreted as a continuation of the preceding field value)
• @simonbaird asks whether we could use an existing standard instead of inventing our own. I would certainly much rather avoid inventing anything if we can: the .tid file format is inspired by the way that headers and body are transmitted with HTTP
• Simon also asks about YAML. I'm really not a fan, for me it has too much inscrutable special behaviour. I don't think we'd want to be dealing with the inevitable end user issues. https://noyaml.com/ makes a better case than I can

[pmario]

Thx Jeremy, Thx Tony

In this case, I think the proposal ends up being overly complex because it essentially turns fields into tiddlers: as soon as we add metadata like a "type" to a field, it just becomes a mini-tiddler. Having two levels of the design with the same general features leads to a lot of complexity.

That's absolutely right. With one of my recent posts I did think about "nesting tiddlers" in fields. IMO technically it would be relatively straight forward. ... It's a nice idea, but adds a lot of "mental" complexity. ...

Which brings up the question: Why doesn't this field contain a transclusion? ...

I do like the idea, that a tiddler can be "self contained" and it can be exported as 1 tiddler. ... On the other hand I did create the bundler plugin, that allows users to "bundle" sets of tiddlers and manage them. ...

May be Tony is right with his approach here: #5805 (reply in thread) ...

I'll need to think about it a bit closer.

[AnthonyMuscio]

Mario, On reflection.

Currently we have the type field that allows a mime type to be set for the tiddler (more specifically the TEXT field ONLY), this then influences how the text field is displayed.

Users and designers can already create other fields, or separate tiddlers than can associate other fields with mime types. I would favour the use of a prefix eg fieldname with fieldname-type containing the mime type.

The missing bit I think is making use of tiddlywikis mime handling on a field other than TEXT, and in the cases where an extra field contains JSON being able to address it tiddler!!filename##index.

If we can expand the tools a little then people can find their own way, eventually we may be able to extend the tiddler format.

I have made it my priority to publish a field and field-type handling solution. And will share it ASAP - I have spent many hours on this already and have good results.

I think when people see this they will be impressed and in a position to develop it further.

Tony

[pmario]

Referring to: #5805 (comment)

Jeremy wrote
In this case, I think the proposal ends up being overly complex because it essentially turns fields into tiddlers: as soon as we add metadata like a "type" to a field, it just becomes a mini-tiddler. Having two levels of the design with the same general features leads to a lot of complexity.

I wrote
That's absolutely right. With one of my recent posts I did think about "nesting tiddlers" in fields. IMO technically it would be relatively straight forward. ... It's a nice idea, but adds a lot of "mental" complexity. ...

Now I thought about it again. We do have very complex type definitions already. We are just not aware about them.
Eg: the tiddler class-field is used by the ViewTemplate in a super complex way.

The ViewTemplate defines "how" the class field is used. So the combination between the field-definition and the template is a complex "type" definition.

I think my configuration is less complex, because it is defined in 1 place and not scattered over several places.

eg: the teaser-field form #5805 (comment)

#/_/mime/teaser: rows="4" minHeight="3em"
teaser: text/plain  | -=-=-=-=-                         <- end-marker config for the parser
line 1
line 2
line 3

• defines the a user-field: teaser
• It defines how the filed should be edited: text-input, 4 lines by default, minimum height: 3 em
• It defines how the fiel should be viewed: as text/plain
• and using the end-marker looks very similar to \define macro() ... \end macro which is used for nested macros now

---

Now I want to try to define that definition using predefined Ontologies

IMO it's a nie:plainTextContent. So the question now is, does using this info add more context to the definition.

#/nie:plainTextContent/teaser: rows="4" minHeight="3em" _endString="-=-=-=-=-"
teaser: line 1
line 2
line 3
-=-=-=-=-

IMO it did and it made the configuration easier too. The description of nie:plainTextContent is:

Plain-text representation of the content of a InformationElement with all markup removed. The main purpose of this property is full-text indexing and search. Its exact content is considered application-specific. The user can make no assumptions about what is and what is not contained within. Applications should use more specific properties wherever possible.

And the context where it is defined NEPOMUK Information Element Ontology actually adds a lot of context.

just some more thoughts while thinking about: A PageTemplate from Scratch #7086

[pmario]

TW tags are defined like this:

tags: a b c 

According to: Generic Annotation Example could also be defined like this:

#/noa:Tag/tags
tags: a b c 

nao:Tag is a Class definition that "Represents a generic tag" and has more information related to it.

The good thing now is, if this definition can be handled by TW the following handling comes for free. Which is very hard to achieve at the moment.

#/noa:Tag/tag-like-field
tag-like-field: a b c