Bug 101774 - Named content in writer; master documents; templates; docbook
Summary: Named content in writer; master documents; templates; docbook
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks: Writer-Enhancements
  Show dependency treegraph
 
Reported: 2016-08-29 13:35 UTC by Zenaan Harkness
Modified: 2017-08-22 11:41 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zenaan Harkness 2016-08-29 13:35:00 UTC
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
Comment 1 Zenaan Harkness 2016-08-29 13:42:22 UTC
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.
Comment 2 Zenaan Harkness 2016-08-29 13:49:00 UTC
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)).
Comment 3 Zenaan Harkness 2016-08-29 13:59:08 UTC
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.
Comment 4 Heiko Tietze 2016-08-29 19:10:20 UTC
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).
Comment 5 Zenaan Harkness 2016-08-29 23:25:32 UTC
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).
Comment 6 Zenaan Harkness 2016-08-29 23:36:37 UTC
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.
Comment 7 Zenaan Harkness 2016-08-29 23:39:45 UTC
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
Comment 8 Zenaan Harkness 2016-08-30 14:37:53 UTC
These might relate to document themes as well - need to analyse further. Adding "see also" for bug #90497
Comment 9 Heiko Tietze 2016-10-12 13:37:35 UTC
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.