Skip to content
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

Bold TextType does not validate #293

Open
isteves opened this issue Apr 2, 2018 · 5 comments
Open

Bold TextType does not validate #293

isteves opened this issue Apr 2, 2018 · 5 comments

Comments

@isteves
Copy link

isteves commented Apr 2, 2018

The function EML::set_methods adds an <emphasis role="strong"> tag to text that is bold, but eml_validate rejects it with this error message: Element 'emphasis', attribute 'Role': The attribute 'Role' is not allowed.

@amoeba
Copy link
Contributor

amoeba commented Apr 2, 2018

Thanks for filing this @isteves. I think this would be a great improvement to get into the next release of EML. EML currently supports emphasis which is described in the DocBook spec as:

Description:
Emphasis provides a method for indicating that certain text should be stressed in some way.

Processing expectations:
Formatted inline. Emphasized text is traditionally presented in italics or boldface. A Role attribute of bold or strong is often used to generate boldface, if italics is the default presentation.

In our presentation of EML in the Metacat View Service, we decided to delegate the look of <emphasis> elements to the user agent by wrapping the emphasized content in an HTML5 <em> tag which is semantic and is typically rendered in italics:

Typically this element is displayed in italic type.

Adding a role attribute to EML's emphasis element would get our DocBook-lite implementation nearer to equivalence with Markdown (which we're working on adding support for).

@srearl
Copy link
Contributor

srearl commented Apr 3, 2018

Hi @amoeba - This is a source of frustration for me also - this along with other DocBook pain points such as the formatting of lists that do not play well with EML. However, won't the proposed change to support markdown formatting (e.g., sensu issue 275) address all such issues such that adding role to emphasis would be superfluous? I am already thinking of new work flows that will take advantage of the markdown support so want to be sure that I understand correctly.

@amoeba
Copy link
Contributor

amoeba commented Apr 3, 2018

Hey @srearl thanks for chiming in!

However, won't the proposed change to support markdown formatting (e.g., sensu issue 275) address all such issues such that adding role to emphasis would be superfluous?

Perhaps superfluous, yes. We have a lot of existing content using the current DocBook-lite schema and the changes adding support for Markdown will not deprecate the DocBook-lite approach. Rather, the two will be valid ways of authoring TextType content. Since we're keeping the DocBook-lite approach to TextType around, I think it'd be nice to round out its support for basic typesetting features by adding text bolding and maybe then we can feature-freeze it. If we do this, users looking to add bold text to their existing EML content won't have to re-write their TextType elements to use Markdown just to get bolding and, instead, they can just adding the role attribute to their emphasis tags. I think people would prefer this over being told to re-write their content in Markdown. On top of that, some groups/systems may automatically generate EML using libraries so they might appreciate this change as well.

his along with other DocBook pain points such as the formatting of lists that do not play well with EML

I'd be interested in hearing more about this pain point. Either here or on Slack (I'm on NCEAS and LTER slacks).

@isteves
Copy link
Author

isteves commented Apr 3, 2018

I'm interested in hearing about this, too! A while ago I was interested in creating bulleted lists that are without paragraph separators between list items, which is supported by DocBook but not by EML:

this:

  • item 1
  • item 2

rather than this:

  • item 1

  • item 2

@srearl not sure if you're thinking along similar lines or not, but I'm definitely looking forward to Markdown, too!

@srearl
Copy link
Contributor

srearl commented Apr 3, 2018

hi @isteves - yes, just chatting with with amoeba in Slack about similar difficulties, especially with lists, which are particularly problematic as it seems you have discovered also. I am very much looking forward to the markdown support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants