Topics

Not using the

element

#mixed-content

Bernard Aschwanden
 

Anyone run into a situation where someone has said "we don't want to use the <p> element in things like note, li, entry, and so on". The <p> element is to be used directly in the <conbody> and the like only. Basically dropping it everywhere. When asked what they'll do if they need two paragraphs in a table cell or a list item (for example) the response is "we'll figure it out later".

Anyone have a good article or a link or ideas on why they SHOULD use the <p> element in all cases? Or a good solution to their other approach? What if they DO NOT use the <p> and later discover they should? The content will be in a CCMS, so if there is a need to make mass structural changes later it can introduce its own set of issues.

The logic was that they don't want to train authors to insert the <p> element if they work with, for example, the <li>. The reasoning is that, clearly this isn't the way you would create a note, li, entry, and so on since "DITA doesn't need the <p> tag and wants to use as few tags as possible".

Genuinely interested in seeing if there are legit arguments on both sides here. We know for sure that, at present, there are cells and lists where items need two or more paragraphs. The same for notes and cautions.

Thanks,

--

Bernard Aschwanden
+1 905 833 8448


Twitter: @aschwanden4stc or @publishsmarter

Jeff Hooker
 

For our XML CCMS deployments we have configured the authoring tools to automatically insert a <p> element into table cells, notes, list items, etc. for the reason that we have many, many, many more "occasional" authors than we do power users, and these occasional authors find it first puzzling, then, frustrating, then angering when they can't insert a second line into the position of their choice. We try not to anger our users.

Among our early mistakes with our XML deployments was consistently overestimating the technical aptitude of engineers. We don't make that mistake any more. 

Cheers,
Jeff.

On Wed, Dec 4, 2019 at 4:31 PM Bernard Aschwanden <bernard.aschwanden@...> wrote:
Anyone run into a situation where someone has said "we don't want to use the <p> element in things like note, li, entry, and so on". The <p> element is to be used directly in the <conbody> and the like only. Basically dropping it everywhere. When asked what they'll do if they need two paragraphs in a table cell or a list item (for example) the response is "we'll figure it out later".

Anyone have a good article or a link or ideas on why they SHOULD use the <p> element in all cases? Or a good solution to their other approach? What if they DO NOT use the <p> and later discover they should? The content will be in a CCMS, so if there is a need to make mass structural changes later it can introduce its own set of issues.

The logic was that they don't want to train authors to insert the <p> element if they work with, for example, the <li>. The reasoning is that, clearly this isn't the way you would create a note, li, entry, and so on since "DITA doesn't need the <p> tag and wants to use as few tags as possible".

Genuinely interested in seeing if there are legit arguments on both sides here. We know for sure that, at present, there are cells and lists where items need two or more paragraphs. The same for notes and cautions.

Thanks,

--

Bernard Aschwanden
+1 905 833 8448


Twitter: @aschwanden4stc or @publishsmarter

Lynne Price
 

 Bernard,
    Most of my projects allow for the possibility of multiple paragraphs in notes, list items, and so forth. Nevertheless, the vast majority of such elements contain only a single paragraph. Models that require such singleton paragraphs to be wrapped in a paragraph element such as <p> result in markup that is cluttered. If I am reading pretty-printed XML, I would much rather see something like:
<li>red</li>
<li>green</li>
<li>blue</li>
then
<li>
   <p>red</p>
</li>
<li>
   <p>green</p>
</li>
<li>
    <p>blue</p>
</li>
The more compact version is easier to read and related content is more likely to fit on a screen. In SGML or FrameMaker, I tend to use content models such as
((#PCDATA | inlines)*, paragraphs*)
where inlines has the form x | y | z ... where x, y,  z and so forth are inline elements that can occur inside a paragraph, and paragraphs is a similar lists of element types that consist of one or more coplete paragraphs.  Although XML requires that when data charaters are permitted they must be allowed throughout the content, I find that users find it natural to group "loose" text at the start of such compound elements.

I do agree with Jeff's comment that software can insert a required <p> at the start of an element, but I still prefer to minimizes the number of total elements.

    --Lynne



On 12/4/2019 1:45 PM, Bernard Aschwanden wrote:
Anyone run into a situation where someone has said "we don't want to use the <p> element in things like note, li, entry, and so on". The <p> element is to be used directly in the <conbody> and the like only. Basically dropping it everywhere. When asked what they'll do if they need two paragraphs in a table cell or a list item (for example) the response is "we'll figure it out later".

Anyone have a good article or a link or ideas on why they SHOULD use the <p> element in all cases? Or a good solution to their other approach? What if they DO NOT use the <p> and later discover they should? The content will be in a CCMS, so if there is a need to make mass structural changes later it can introduce its own set of issues.

The logic was that they don't want to train authors to insert the <p> element if they work with, for example, the <li>. The reasoning is that, clearly this isn't the way you would create a note, li, entry, and so on since "DITA doesn't need the <p> tag and wants to use as few tags as possible".

Genuinely interested in seeing if there are legit arguments on both sides here. We know for sure that, at present, there are cells and lists where items need two or more paragraphs. The same for notes and cautions.


_._,_._,_


-- 
Lynne A. Price
Text Structure Consulting, Inc.
Specializing in structured FrameMaker consulting, application development, and training
lprice@...            http://www.txstruct.com
voice/fax: (510) 583-1505      cell phone: (510) 421-2284

Nicholas Mucks
 

Hi Bernard,

On a personal note, I started in dita as a tech writer and wanted “pure” block elements, so no embedded p tags. Over time, and as I moved into an information architecture role, I find p elements to be very practical. Your plugins just need to handle inconsistent markup by stripping the p of top and bottom space when in tables or other elements. You can add Schematron patterns to help writers use better markup. 

This might be helpful:

On Dec 4, 2019, at 1:45 PM, Bernard Aschwanden <bernard.aschwanden@...> wrote:

Anyone run into a situation where someone has said "we don't want to use the <p> element in things like note, li, entry, and so on". The <p> element is to be used directly in the <conbody> and the like only. Basically dropping it everywhere. When asked what they'll do if they need two paragraphs in a table cell or a list item (for example) the response is "we'll figure it out later".

Anyone have a good article or a link or ideas on why they SHOULD use the <p> element in all cases? Or a good solution to their other approach? What if they DO NOT use the <p> and later discover they should? The content will be in a CCMS, so if there is a need to make mass structural changes later it can introduce its own set of issues.

The logic was that they don't want to train authors to insert the <p> element if they work with, for example, the <li>. The reasoning is that, clearly this isn't the way you would create a note, li, entry, and so on since "DITA doesn't need the <p> tag and wants to use as few tags as possible".

Genuinely interested in seeing if there are legit arguments on both sides here. We know for sure that, at present, there are cells and lists where items need two or more paragraphs. The same for notes and cautions.

Thanks,

--

Bernard Aschwanden
+1 905 833 8448


Twitter: @aschwanden4stc or @publishsmarter

Mica Semrick
 

Hi all,

In my mind you can't just strip space from <p> inside elements like <li> or a table cell, since multiparagraph table cells and list items are a thing people want to do.

The minimal markup in this case is:
<li>First part
<p>second part</p>
</li>

This will give your list item and paragraph proper spacing.

If you're using an editor that supports schematron rules, you could craft a rule that gently nags authors when they use something like <li><p>too much space!</p></li>.

-m


On December 4, 2019 7:44:53 PM PST, "Nicholas Mucks via Groups.Io" <urbanrobots@...> wrote:
Hi Bernard,

On a personal note, I started in dita as a tech writer and wanted “pure” block elements, so no embedded p tags. Over time, and as I moved into an information architecture role, I find p elements to be very practical. Your plugins just need to handle inconsistent markup by stripping the p of top and bottom space when in tables or other elements. You can add Schematron patterns to help writers use better markup. 

This might be helpful:
https://www.oxygenxml.com/dita/styleguide/webhelp-feedback/#Artefact/Syntax_and_Markup/c_Paragraphs.html

Take care,
- Nick

Sent from mobile

On Dec 4, 2019, at 1:45 PM, Bernard Aschwanden <bernard.aschwanden@...> wrote:

Anyone run into a situation where someone has said "we don't want to use the <p> element in things like note, li, entry, and so on". The <p> element is to be used directly in the <conbody> and the like only. Basically dropping it everywhere. When asked what they'll do if they need two paragraphs in a table cell or a list item (for example) the response is "we'll figure it out later".

Anyone have a good article or a link or ideas on why they SHOULD use the <p> element in all cases? Or a good solution to their other approach? What if they DO NOT use the <p> and later discover they should? The content will be in a CCMS, so if there is a need to make mass structural changes later it can introduce its own set of issues.

The logic was that they don't want to train authors to insert the <p> element if they work with, for example, the <li>. The reasoning is that, clearly this isn't the way you would create a note, li, entry, and so on since "DITA doesn't need the <p> tag and wants to use as few tags as possible".

Genuinely interested in seeing if there are legit arguments on both sides here. We know for sure that, at present, there are cells and lists where items need two or more paragraphs. The same for notes and cautions.

Thanks,

--

Bernard Aschwanden
+1 905 833 8448


Twitter: @aschwanden4stc or @publishsmarter

despopoulos_chriss
 

For <p> in notes, list items, and table entries, etc.  Mica lists this minimal markup:
<li>First part
<p>second part</p>
</li>

And Lynne points out that markup readability is inversely proportional to the distance from minimal markup.

I think there's a trade-off here.  If you impose a <p> for the First Part entry, then you have consistency in the markup, and consistency in the processing.  So I believe the question is where you want to put the cost -- process implementation and maintenance, or code readability and authoring.  In our case we're a small, DIY team, implementing unique processes.  So we opted for putting the cost on the authoring side. 

That said, it seems that CSS to PDF (in oXygen at least) doesn't like notes with a <p> in the first part...  The "NOTE" statement ends up on a separate line, and I don't think we have figured out how to merge it into the first part text.  There probs are some less-than-obvious CSS tricks to do that, but who has the time?  So we shrugged our shoulders and left it as is.  That's better than breaking/fixing our on-the-fly transform to HTML. 

The point being, it's a trade-off, and like all trade-offs it is not black and white.

Kristen James Eberlein
 

Hi, Bernard.

Are these folks planning to constrain DITA elements to make <p> not available?

Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)

On 12/4/2019 4:45 PM, Bernard Aschwanden wrote:
Anyone run into a situation where someone has said "we don't want to use the <p> element in things like note, li, entry, and so on". The <p> element is to be used directly in the <conbody> and the like only. Basically dropping it everywhere. When asked what they'll do if they need two paragraphs in a table cell or a list item (for example) the response is "we'll figure it out later".

Jan Benedictus
 

Hi

Fonto implementations for DITA (including the https://dita.demo.fontoxml.com ) usually include the configuration of the editor so that it will wrap text in a <p> - not only in a list . We do this "clean-up" when loading the document in the editor - and automatically generate the necessary <p>s when authoring.

Reason is very much the SME's perspective: The possibility to have multiple paragraphs of text within one bullet (or Note for that matter), ís expected behaviour - done using Shift-Enter.  
Even if the schema allows mixed content (Text + Ps mixed) we see no added value in allowing inconsistency. (By the way, I believe that the schema even allows Text within a List, but outside a List-item? - we also clean up those cases.)

Cheers!
Jan






Jan Benedictus

CEO

jan.benedictus@...

+31 70 319 19 23

+31 61 448 23 03 




On Thu, 5 Dec 2019 at 13:19, Kristen James Eberlein <kris@...> wrote:
Hi, Bernard.

Are these folks planning to constrain DITA elements to make <p> not
available?

Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)

On 12/4/2019 4:45 PM, Bernard Aschwanden wrote:
> Anyone run into a situation where someone has said "we don't want to
> use the <p> element in things like note, li, entry, and so on". The
> <p> element is to be used directly in the <conbody> and the like only.
> Basically dropping it everywhere. When asked what they'll do if they
> need two paragraphs in a table cell or a list item (for example) the
> response is "we'll figure it out later".
>



Bernard Aschwanden
 

All good suggestions to this point. My concern is that the client wanted to truly remove the option for a <p> element from the LI or the NOTE and so on. Not allow it at all. Basically force authors to a single string. They would leave it for the conbody or the section/example, but no option at all for the others. That was the part that felt odd to me. 


On Wed., Dec. 4, 2019, 4:45 p.m. Bernard Aschwanden, <bernard.aschwanden@...> wrote:
Anyone run into a situation where someone has said "we don't want to use the <p> element in things like note, li, entry, and so on". The <p> element is to be used directly in the <conbody> and the like only. Basically dropping it everywhere. When asked what they'll do if they need two paragraphs in a table cell or a list item (for example) the response is "we'll figure it out later".

Anyone have a good article or a link or ideas on why they SHOULD use the <p> element in all cases? Or a good solution to their other approach? What if they DO NOT use the <p> and later discover they should? The content will be in a CCMS, so if there is a need to make mass structural changes later it can introduce its own set of issues.

The logic was that they don't want to train authors to insert the <p> element if they work with, for example, the <li>. The reasoning is that, clearly this isn't the way you would create a note, li, entry, and so on since "DITA doesn't need the <p> tag and wants to use as few tags as possible".

Genuinely interested in seeing if there are legit arguments on both sides here. We know for sure that, at present, there are cells and lists where items need two or more paragraphs. The same for notes and cautions.

Thanks,

--

Bernard Aschwanden
+1 905 833 8448


Twitter: @aschwanden4stc or @publishsmarter

CharJTF
 

We don't include <p> in <note> because we were getting "Note:" at the bottom of one page and the note text at the top of the next page. Not using <p> means that the note is always on one page. (In our implementation of Arbortext, <p> isn't automatically added to <note>.) The only time we might run into issues are multi-para notes.

We include <p> in <li> (all parts for multi-paragraph list items) and in table cells so that the spacing above and below is consistent across the row. In our implementation, <p> is automatically included in <li> but not in table cells. (This means that we add <p> to all cells, but it's easy to do because we can select the entire table, and then select <p>. If writers forget, the table usually publishes without issue, unless one column has <p> and the other column doesn't.)

Char

On Thu, Dec 5, 2019 at 7:47 AM Bernard Aschwanden <bernard.aschwanden@...> wrote:
All good suggestions to this point. My concern is that the client wanted to truly remove the option for a <p> element from the LI or the NOTE and so on. Not allow it at all. Basically force authors to a single string. They would leave it for the conbody or the section/example, but no option at all for the others. That was the part that felt odd to me. 

On Wed., Dec. 4, 2019, 4:45 p.m. Bernard Aschwanden, <bernard.aschwanden@...> wrote:
Anyone run into a situation where someone has said "we don't want to use the <p> element in things like note, li, entry, and so on". The <p> element is to be used directly in the <conbody> and the like only. Basically dropping it everywhere. When asked what they'll do if they need two paragraphs in a table cell or a list item (for example) the response is "we'll figure it out later".

Anyone have a good article or a link or ideas on why they SHOULD use the <p> element in all cases? Or a good solution to their other approach? What if they DO NOT use the <p> and later discover they should? The content will be in a CCMS, so if there is a need to make mass structural changes later it can introduce its own set of issues.

The logic was that they don't want to train authors to insert the <p> element if they work with, for example, the <li>. The reasoning is that, clearly this isn't the way you would create a note, li, entry, and so on since "DITA doesn't need the <p> tag and wants to use as few tags as possible".

Genuinely interested in seeing if there are legit arguments on both sides here. We know for sure that, at present, there are cells and lists where items need two or more paragraphs. The same for notes and cautions.

Thanks,

--

Bernard Aschwanden
+1 905 833 8448


Twitter: @aschwanden4stc or @publishsmarter

Dan Vint
 

Removing the option seems wrong unless there content is so simple/controlled that lists and notes would never have a second paragraph. I suppose it is possible, but it seems like there is always that one situation where 2 is absolutely required - then what does the writer do.

Probably less of an issue in a list item, but notes I would think it comes up often. I can see the writer just putting in 2 note elements to work around this, but the presentation would be odd and you would loose the continuity by doing that.



Sent from my Verizon, Samsung Galaxy smartphone


-------- Original message --------
From: Bernard Aschwanden <bernard.aschwanden@...>
Date: 12/5/19 5:47 AM (GMT-07:00)
To: dita-users@groups.io
Subject: Re: [dita-users] Not using the <p> element

All good suggestions to this point. My concern is that the client wanted to truly remove the option for a <p> element from the LI or the NOTE and so on. Not allow it at all. Basically force authors to a single string. They would leave it for the conbody or the section/example, but no option at all for the others. That was the part that felt odd to me. 

On Wed., Dec. 4, 2019, 4:45 p.m. Bernard Aschwanden, <bernard.aschwanden@...> wrote:
Anyone run into a situation where someone has said "we don't want to use the <p> element in things like note, li, entry, and so on". The <p> element is to be used directly in the <conbody> and the like only. Basically dropping it everywhere. When asked what they'll do if they need two paragraphs in a table cell or a list item (for example) the response is "we'll figure it out later".

Anyone have a good article or a link or ideas on why they SHOULD use the <p> element in all cases? Or a good solution to their other approach? What if they DO NOT use the <p> and later discover they should? The content will be in a CCMS, so if there is a need to make mass structural changes later it can introduce its own set of issues.

The logic was that they don't want to train authors to insert the <p> element if they work with, for example, the <li>. The reasoning is that, clearly this isn't the way you would create a note, li, entry, and so on since "DITA doesn't need the <p> tag and wants to use as few tags as possible".

Genuinely interested in seeing if there are legit arguments on both sides here. We know for sure that, at present, there are cells and lists where items need two or more paragraphs. The same for notes and cautions.

Thanks,

--

Bernard Aschwanden
+1 905 833 8448


Twitter: @aschwanden4stc or @publishsmarter

Chris Papademetrious
 

Our writers regularly create content using multiple <p> in notes, list items, and table cells. We also occasionally include other content, such as preformatted text blocks and (sub)lists.

 - Chris

Lynne Price
 

On 12/5/2019 4:47 AM, Bernard Aschwanden wrote:
All good suggestions to this point. My concern is that the client wanted to truly remove the option for a <p> element from the LI or the NOTE and so on. Not allow it at all. Basically force authors to a single string. They would leave it for the conbody or the section/example, but no option at all for the others. That was the part that felt odd to me.
Bernard,
   Preventing multi-paragraph lists seems odd to me as well. One exception is military documents where every paragraph must be numbered. Thus a multi-paragraph list item in effect contains a sublist.

    --Lynne

--
Lynne A. Price
Text Structure Consulting, Inc.
Specializing in structured FrameMaker consulting, application development, and training
lprice@... http://www.txstruct.com
voice/fax: (510) 583-1505 cell phone: (510) 421-2284

Kristen James Eberlein
 

Constraining table cells, <li>, and <note> to NOT allow <p> sounds like a disaster in the making for most environments.

Technical writers will devise hellacious workarounds, and non-technical authors will be frustrated.

It sounds as if the client wants to minimize style sheet development ... I suspect that the cost of handling the  ensuing frustration and dealing with the "creative" workarounds will be more expensive in the long run.
--
-- 
Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting LLC
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)

Joe Williams
 

The part of the original message that gives me pause is "we'll figure it out later". In my experience, that can be asking for trouble (i.e., avoidable technical debt in the future at a time not of your choosing).

Mica Semrick
 

Hey Chris,

\On 12/5/19 2:17 AM, despopoulos_chriss via Groups.Io wrote:
The "NOTE" statement ends up on a separate line, and I don't think we have figured out how to merge it into the first part text.  There probs are some less-than-obvious CSS tricks to do that, but who has the time?
Something like:

.note > :first-child {
display: inline;
}

Should do the trick. You probably also want to add margin-top: 0; and padding-top: 0; to that, so the spacing is consistent.

-m

Michael Priestley
 

For what it's worth, for LwDITA we went the path of requiring the <p> everywhere instead.

Once it's required, most authoring tools will add the first one automatically, so no extra burden on the author, and it lets them add more when needed.

As a bonus, it means that any paragraph is now easily reusable/replaceable with conref. So you can easily reuse paragraphs across structures like lists, table, sections.

Michael Priestley, Senior Technical Staff Member (STSM)
Taxonomy Specialist, Marketing Analytics
mpriestl@...




From:        "Bernard Aschwanden" <bernard.aschwanden@...>
To:        dita-users@groups.io
Date:        2019/12/05 10:54 AM
Subject:        [EXTERNAL] Re: [dita-users] Not using the <p> element
Sent by:        dita-users@groups.io




All good suggestions to this point. My concern is that the client wanted to truly remove the option for a <p> element from the LI or the NOTE and so on. Not allow it at all. Basically force authors to a single string. They would leave it for the conbody or the section/example, but no option at all for the others. That was the part that felt odd to me. 


On Wed., Dec. 4, 2019, 4:45 p.m. Bernard Aschwanden, <bernard.aschwanden@...> wrote:
Anyone run into a situation where someone has said "we don't want to use the <p> element in things like note, li, entry, and so on". The <p> element is to be used directly in the <conbody> and the like only. Basically dropping it everywhere. When asked what they'll do if they need two paragraphs in a table cell or a list item (for example) the response is "we'll figure it out later".

Anyone have a good article or a link or ideas on why they SHOULD use the <p> element in all cases? Or a good solution to their other approach? What if they DO NOT use the <p> and later discover they should? The content will be in a CCMS, so if there is a need to make mass structural changes later it can introduce its own set of issues.

The logic was that they don't want to train authors to insert the <p> element if they work with, for example, the <li>. The reasoning is that, clearly this isn't the way you would create a note, li, entry, and so on since "DITA doesn't need the <p> tag and wants to use as few tags as possible".

Genuinely interested in seeing if there are legit arguments on both sides here. We know for sure that, at present, there are cells and lists where items need two or more paragraphs. The same for notes and cautions.

Thanks,

--

Bernard Aschwanden
bernard.aschwanden@...
+1 905 833 8448
www.publishingsmarter.com

https://www.gotomeet.me/PublishingSmarter

Twitter: @aschwanden4stc or @publishsmarter



Jeff Hooker
 

Hi Lynne,

I assume that you're actually looking at the XML in text form when authoring (at least, it sounds like you are). This is a condition that we actively discourage for our authors. Once again, for us this comes back to the preponderance of "occasional" authors and our steady re-education regarding the technical aptitude of technical people.

Cheers,
Jeff.

On Wed, Dec 4, 2019 at 5:49 PM Lynne Price <lprice@...> wrote:
 Bernard,
    Most of my projects allow for the possibility of multiple paragraphs in notes, list items, and so forth. Nevertheless, the vast majority of such elements contain only a single paragraph. Models that require such singleton paragraphs to be wrapped in a paragraph element such as <p> result in markup that is cluttered. If I am reading pretty-printed XML, I would much rather see something like:
<li>red</li>
<li>green</li>
<li>blue</li>
then
<li>
   <p>red</p>
</li>
<li>
   <p>green</p>
</li>
<li>
    <p>blue</p>
</li>
The more compact version is easier to read and related content is more likely to fit on a screen. In SGML or FrameMaker, I tend to use content models such as
((#PCDATA | inlines)*, paragraphs*)
where inlines has the form x | y | z ... where x, y,  z and so forth are inline elements that can occur inside a paragraph, and paragraphs is a similar lists of element types that consist of one or more coplete paragraphs.  Although XML requires that when data charaters are permitted they must be allowed throughout the content, I find that users find it natural to group "loose" text at the start of such compound elements.

I do agree with Jeff's comment that software can insert a required <p> at the start of an element, but I still prefer to minimizes the number of total elements.

    --Lynne



On 12/4/2019 1:45 PM, Bernard Aschwanden wrote:
Anyone run into a situation where someone has said "we don't want to use the <p> element in things like note, li, entry, and so on". The <p> element is to be used directly in the <conbody> and the like only. Basically dropping it everywhere. When asked what they'll do if they need two paragraphs in a table cell or a list item (for example) the response is "we'll figure it out later".

Anyone have a good article or a link or ideas on why they SHOULD use the <p> element in all cases? Or a good solution to their other approach? What if they DO NOT use the <p> and later discover they should? The content will be in a CCMS, so if there is a need to make mass structural changes later it can introduce its own set of issues.

The logic was that they don't want to train authors to insert the <p> element if they work with, for example, the <li>. The reasoning is that, clearly this isn't the way you would create a note, li, entry, and so on since "DITA doesn't need the <p> tag and wants to use as few tags as possible".

Genuinely interested in seeing if there are legit arguments on both sides here. We know for sure that, at present, there are cells and lists where items need two or more paragraphs. The same for notes and cautions.


Lynne Price
 

On 12/5/2019 12:03 PM, Jeff Hooker wrote:
I assume that you're actually looking at the XML in text form when authoring (at least, it sounds like you are). This is a condition that we actively discourage for our authors. Once again, for us this comes back to the preponderance of "occasional" authors and our steady re-education regarding the technical aptitude of technical people.
Jeff,
   Not necessarily. I'm thinking of any model (XML or not, text or graphic) that displays element structure to users, both end-users and developers. I don't like models that force extra elements. And I almost always prefer to simplify the end-user view even if it means that developers need to consider more contexts.
   By the way, I prefer to design for the convenience of end-users and am very much aware that there are situations in which most editing is done by occasional authors. I nevertheless feel that educated end-users can be much more productive than occasional authors. A schema designed for educated users can be much more help in enforcing the requirements of particular document sets.

    --Lynne

--
Lynne A. Price
Text Structure Consulting, Inc.
Specializing in structured FrameMaker consulting, application development, and training
lprice@... http://www.txstruct.com
voice/fax: (510) 583-1505 cell phone: (510) 421-2284

Jeff Hooker
 

No argument about educated vs. occasional, vis-a-vis productivity.

The nature of the deployments I've been doing for the last 15 years are to groups of engineers in the semiconductor design space. The nature of their jobs is spending perhaps 2-3 months of the year designing a product (aka, authoring design documents) and then the remaining months actually engaged with design tools and technologies instead of the CCMS. This gives them ample opportunity to forget everything they knew, and at the same time the CCMS is constantly evolving in their absence. This is not the setting in which anyone achieves mastery.

It looks like we're finally going to deploy a browser-based authoring interface in the coming year, which I'm quite hopeful will serve the needs of our occasional user base better than the desktop client/authoring tools we currently deploy.

Cheers,
Jff.

On Thu, Dec 5, 2019 at 1:11 PM Lynne Price <lprice@...> wrote:
On 12/5/2019 12:03 PM, Jeff Hooker wrote:
> I assume that you're actually looking at the XML in text form when
> authoring (at least, it sounds like you are). This is a condition that
> we actively discourage for our authors. Once again, for us this comes
> back to the preponderance of "occasional" authors and our steady
> re-education regarding the technical aptitude of technical people.
Jeff,
    Not necessarily. I'm thinking of any model (XML or not, text or
graphic) that displays element structure to users, both end-users and
developers. I don't like models that force extra elements. And I almost
always prefer to simplify the end-user view even if it means that
developers need to consider more contexts.
    By the way, I prefer to design for the convenience of end-users and
am very much aware that there are situations in which most editing is
done by occasional authors. I nevertheless feel that educated end-users
can be much more productive than occasional authors. A schema designed
for educated users can be much more help in enforcing the requirements
of particular document sets.

     --Lynne

--
Lynne A. Price
Text Structure Consulting, Inc.
Specializing in structured FrameMaker consulting, application development, and training
lprice@...            http://www.txstruct.com
voice/fax: (510) 583-1505      cell phone: (510) 421-2284