-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
the documentation about metadata is a bit fragmented #4584
Comments
I tend to agree... part of the story is also in the templates section. Hopefully, I get to work on #1960 soon. Then we could consider moving the Metadata blocks extension section from the markdown extensions to the general extensions part... See also the wiki for some further links to potential changes in the future... |
It would be very helpful to have a comparison table showing the fields which can be traded between different formats, with particular regard to metadata information. That would greatly help to make it clear, what Pandoc presently can and what it cannot, and which "granularity" is provided. Let me begin with what I learnt so far:
Does anybody have a more complete table? Or who would like to contribute to write one? |
@Zack-83 it's a good initiative, but i am afraid that maintaining such a table would be too demanding and it will end up getting outdated. Also the relational, tabular structure does not suit the actual data model used within pandoc, which is based on the native format, and readers and writes from and to every supported format. About this, i admit that i have some doubts about the data model for metadata. As far as i understood skimming through Definitions.hs in pandoc-types, there is no fixed set of metadata: they are simply strings that are managed by convention. Do we want to turn them into a defined set? |
btw, you can see which are used how with e.g. |
Francesco Occhipinti <[email protected]>
writes:
About this, i admit that i have some doubts about
the data model for metadata. As far as i understood
skimming through Definitions.hs in pandoc-types,
there is no fixed set of metadata: they are simply
strings that are managed by convention. Do we want
to turn them into a defined set?
Having a data structure with types for the metadata
would be good in lots of ways. It would then be clear
which metadata fields writers and readers ought to
support. On the other hand, this would reduce
flexibility for users to define their own metadata.
Perhaps a compromise would be to have some hard-coded
"must-support" fields, and a map of optional fields.
(Indeed, we used to have hard-coded title, author,
and date -- and that's all -- before we added YAML
metadata. At that point it seemed silly to keep
the hard-coded fields, but maybe that was the wrong
decision.)
Perhaps this should be discussed on pandoc-discuss or
a new issue. In any case, this issue isn't the right
place to discuss this further.
|
The documentation about metadata is currently part of a section about Pandoc's markdown while it could be a dedicated section with info about readers and writers in order to avoid duplication. Here i express some doubts about the handling metadata are supposed to receive, while here @jkr has doubts about how to document metadata handling for the DOCX writer.
Metadata are part of the data model, and supported to various degrees by the different readers and writers, therefore i would suggest to document them in a section where the intended semantic is explained first, followed by sections about metadata handling in specific readers or writers.
The text was updated successfully, but these errors were encountered: