Comment 32 (https://bugs.documentfoundation.org/show_bug.cgi?id=50699#c32) of bug #50699 leads me to file this enhancement suggestion (I think this naturally supercedes bug #50699): allow for named content. Content can be: - text, with or without para/char style - image, graphic - table, list - frame (optionally with some content) - OLE/UNO embedded objects - file/sheet/cell-range - macro - formula - field (e.g. page number field) basically anything that can be inserted into a Writer document, should be able to be named as a "content entity" or just "entity", as in SGML and DocBook. Similar to SGML entities, see: https://en.wikipedia.org/wiki/SGML See also DocBook's semantic element tags: https://en.wikipedia.org/wiki/Docbook These named content "entity" instances might be most useful in a Master document or template. Or, UI might suggest an "entity template" (new type of file) (or not). This feature would be the beginning of "semantic markup" support, in the style of SGML and docbook. Gotta start somewhere :) Certainly, the implementation of this feature would naturally then call for a "semantic content" view, and ultimately additional DocBook style "output production" views, which are almost identical to the "named entity/content" view. The initial representation/ storage/ editing format should perhaps match DocBook's XML preference. Serious consideration to whether to support the following needs developer checkin, at least in the long term: - arbitrary schemas (user defined/ downloaded) - specific schemas (DocBook, ...) - no specific schema, just user defined - output transformations (refer DocBook), vs internal/ LO GUI and user usage of these entities
Changed my mind, this does not supercede bug #50699, but instead is the prerequisite for 50699 to be able to be implemented cleanly. This dependency is now included.
This feature (101774) is closely related to and would tie in nicely with enchancement bug #101772. To properly replace DreamWeaver proprietary product, an effective and powerful templating mechanism is required. Named entities (named bits of content) is the basis of any and all templated content. DocBook (in current XML flavour) and the like and in particular the "entity" or "named content" concept, are the fundamental way to create, share and otherwise implement a powerful templating facility (as powerful as the users choose to make their templates (aka "as complex as they need", where one template/ document references other templates/ subdocuments/ named entities)).
Additionally, note that the following are transformable between each other - possibly with just a little "imposed structure" (i.e. schema) in more generic (less expressive) markup languages as compared to those more expressive/ more specific/ less generic: - XML - YAML (!) - JSON - SGML (Lisp style not so fashionable these days) - PDL (perl data language) - protobuf - SML anything really, as long as its text based and human editable. Otherwise, if it's binary based, a custom entity-editing GUI/view would have to be provided by LO. The serialization format (XML, YAML etc) can with just a little imposed schema/ structure, simply be a plugin. The entity view needs to be readily viewable :) (think split panes, new window, custom "entity domain-specific viewer" view etc). For the power of fully generic pluggable entity type viewers, check out Eclipse IDE and its workspaces and numerous views - very powerful.
Could you please elaborate what is missing from your point of view. I mean you can easily set a name for tables, images, charts etc. (you find the option in the properties dialog).
Thanks for the explaining this need to clarify. - "Named content" in this concept is content that can be displayed in another document. - And, named content can be "referenced by name" and included, multiple times (in this or another document). - And so content can be created also by declaring other named bits of content. In DocBook for example, when referencing a file containing named content, by relative or absolute filename, or by "system catalog name", then all those names become available in the current file, and will appear in a normal or print view of the file, and the "reference names" only would appear in a "source" or "raw xml" view of the file/document (also, there might be a 'named content' view created to act as a convenient visual library of named content).
My third example: - And so content can be created also by declaring other named bits of content. can be further clarified: Named content, being content that is included by a reference to the name of the content you want to include "right here", can also be created in a nested fashion, e.g.: <content name="username">Heiko Tietze</> <content name="postal-address"> P.O. Box 33 Attractive Boulevarde Some Suburb 88888 </> <content name="full-address"> <content-ref>&username</> <content-ref>&postal-address</> </> Then, assuming say that these "named entities" are declared in the master document, or in some file that is otherwise referenecable, then in a new document, I could do the following: Insert -> Named content... And then choose "&full-address" from the drop down list. Then, in my "normal" or "web" view of the document, my full address would appear, and it would be like an LO "field" - so it would not ordinarily be editable. Of course editing and locking various named content would be a UI feature - if it is edited, it would --always-- be the original "definition" that is being changed. In essence, this is how DocBook and various templating tools work.
Also, what I mean by "will appear in a normal or print view of the file" was unclear, it should say: - all the entities declared in a referenced file containing declared or "named" content, are available to be inserted as "entity fields" in the current document; - and, when a named entity is inserted into the current document, the content of the "name reference" and not the name itself, will then appear in a Normal View or Print View
These might relate to document themes as well - need to analyse further. Adding "see also" for bug #90497
I wonder if some use cases can be done with variables. But any content should be named, so far I agree. Lets see what others think.
Old ticket, no further input- so let's remove the UX flag and have developers doing their magic.