Bug 1014455 - Abstracts with more than one <para> fail
Summary: Abstracts with more than one <para> fail
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: PressGang CCMS
Classification: Community
Component: CCMS-Core
Version: 1.1
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ---
: 1.3
Assignee: Lee Newson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 1012194
TreeView+ depends on / blocked
 
Reported: 2013-10-02 05:42 UTC by Ruediger Landmann
Modified: 2013-12-03 22:16 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-03 22:16:23 UTC


Attachments (Terms of Use)
Abstract topic (16.42 KB, image/png)
2013-11-24 22:51 UTC, Matthew Casperson
no flags Details

Description Ruediger Landmann 2013-10-02 05:42:23 UTC
Description of problem:
You cannot specify an abstract with more than one <para> in the topic map

Version-Release number of selected component (if applicable):
1.1

How reproducible:
100%

Steps to Reproduce:
1. Create a topic map and try to find a way to specify an abstract with more than one <para>

Actual results:
Do not find a way. Newlines add to a validity errors, whether or not surrounded by quotemarks or square brackets. 

Expected results:
<abstract>s can contain an unrestricted number of child <para>s; there should be a way to specify this. 

Additional info:
Square brackets would be consistent with the syntax for specifying publican.cfg parameters. 

Quotemarks also get escaped and rendered verbatim as in bug 1014452

Comment 1 Lee Newson 2013-11-12 22:59:08 UTC
I've done a partial implementation on this, however I'd like to brain storm with the team about a better way to display multiple paragraph abstracts in a content spec. With the current implementation the format is:

Title = Content Spec Processor Guide
Subtitle = Using the Content Spec Processor for Topic-based Authoring
Abstract = [<para>A guide to using the Content Spec Processor subsystem of Skyn$
<para>Testing having multiple abstracts.</para>]
Product = Engineering Content Services
Version = 1
Copyright Holder = Red Hat, Inc

So basically whatever is placed between the square braces is placed directly inside the <abstract> block in Book_Info.xml. The content is also validated to make sure it is valid XML as per BZ#1019013. The above would also allow for formalpara and simpara to be used instead of whatever you use just being wrapped in a <para>.

Comment 2 Lee Newson 2013-11-13 07:16:44 UTC
After talking to the team, we've decided to store more complex abstracts as a topic as it keeps the Content Spec cleaner and allows for more expansion. To use a topic as the abstract you need to do the following:

Use an abstract with an id, eg:

Abstract = [24991, rev: 400000]

or

Abstract = [N, Abstract]

When creating the topic via the UI, you should make the topic appear as is in Book_Info.xml. eg:

<abstract>
  <para>
    This is the first paragraph in the abstract.
  </para>
  <para>
    This is the second paragraph in the abstract.
  </para>
</abstract>

and then make sure it is tagged with the "Abstract" topic type tag.

Comment 5 Matthew Casperson 2013-11-24 22:23:39 UTC
When attempting to create a new Abstract with the syntax

Abstract = [N, Abstract]

I get the error:

ERROR: Line 6: Invalid Topic! Writer name doesn't exist.
       -> Abstract [N, Abstract]
ERROR: The Content Specification is not valid.

This is actually the expected behaviour, but I'll note it here for clarification. The syntax that should be used when creating a new Abstract topic is:

Abstract = [N, Abstract, writer=mcaspers]

Comment 6 Matthew Casperson 2013-11-24 22:36:58 UTC
Confirmed that a new topic is created with the syntax:

Abstract = [N, Abstract, writer=mcaspers]

Comment 7 Matthew Casperson 2013-11-24 22:51:43 UTC
Created attachment 828452 [details]
Abstract topic

Comment 8 Matthew Casperson 2013-11-24 22:52:29 UTC
When built with CSProcessor client version: 1.3-SNAPSHOT, Build 201311211312 I get the result in the previously attached screenshot.

Comment 9 Lee Newson 2013-11-25 01:01:53 UTC
This is actually a bug in the saving mechanism, as the Content Spec has the following after a new abstract has been created:

Abstract = Abstract [43397]

Since that isn't the syntax for a Meta Data topic it is reverting back to the normal mechanism which is to assume the input is just plain text. Perhaps the validation should be expanded to see if the abstract matches a regular topics syntax and produce a warning.

Comment 10 Lee Newson 2013-11-25 01:37:53 UTC
Fixed in 1.3-SNAPSHOT build 201311251126

The merge mechanism wasn't updating the node type and as such when it was being rendered as text it was reverting to the old mechanism which would display the output as above.

Also I'm going to leave this as assigned for now so that I can look into updating the validation to pick up possible invalid topics.

Comment 11 Lee Newson 2013-11-25 01:39:45 UTC
Note: The above version is currently live on the development/test server.

Comment 15 Lee Newson 2013-11-29 06:00:40 UTC
Since you can't accurately determine if the syntax matches a topic due to the multiple different ways a topic can be defined, I've updated the parser to check if what would be classed as the Topic Title matches the metadata key and if it does it'll remove it and then parse the metadata topic as per normal.


Note You need to log in before you can comment on or make changes to this bug.