RE: [dita] Issue: <text> should be allowed just about everywhere and it'snot

[Robert D Anderson <robander@us.ibm.com>]

I think this is a 1.3 item. For 1.2, we have done exactly what was called
for in the proposal, which was to add <text> into elements that have
#PCDATA but do not allow ph or keyword. I remember a lot of discussion
about whether text should be limited to those elements or allowed more
widely, and I think that opening up that discussion again now means redoing
most of that proposal. In my understanding, the intent was to limit the new
element as described, and to leave keyword as the primary unit of reuse for
small items.

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit





Do we treat this as a request for enhancement in DITA 1.3 or a bug fix
in 1.2? If the latter, we should probably check for other elements that
the original proposal omitted. I wonder how common this use case (and
others similar to it) would be in the year or two it's likely to take
between now and our subsequent spec release (1.3 or 2.0, whatever it
ends up being)...


/Gershon

-----Original Message-----
From: ekimber [mailto:ekimber@reallysi.com]
Sent: Friday, September 11, 2009 9:16 PM
To: dita
Subject: [dita] Issue: <text> should be allowed just about everywhere
and it's not

On dita-users was raised this question:

> We have a writer that would like to conref parts of filepath contents.

> The logical way to do this is to conref on <ph> inside <filepath>.
> Unfortunately the DTD does not allow <ph> inside <filepath> in DITA
> 1.1

The 1.2 <text> element was intended to solve exactly this problem.

However, looking at the declaration for filepath in the 1.2
declarations, <text> is not allowed.

In reviewing proposal 12020, it says:

"The text element should be added to any element which allows #PCDATA
but does not allow ph or keyword."

It then lists elements that meet this criteria. However, filepath is not
listed even though it does not allow ph.

That is, there is requirement is that if an element does not allow at
least ph, it must allow <text>, because it would be wrong, I think, to
use <keyword> purely for the purpose of enabling conref to text
fragments that are not otherwise semantically keywords, which is the
case in the original poster's case

That is, they specifically see using keyword in this case as tag abuse,
and I agree. For example, many presentation styles will make keywords
bold by default, which would definitely not be the desired result in
this case (using conref to a keyword just to build up a file path from
common parts).

So I think that proposal 12020 was either in error in that the only
relevant variable is the presence of <ph>, not <keyword>.

The implication of my analysis is that any element type that does not
allow <ph> in 1.1 must allow <text>, regardless of whether or not
<keyword> is allowed.

Cheers,

E.



----
Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
office: 610.631.6770 | cell: 512.554.9368 2570 Boulevard of the Generals
| Suite 213 | Audubon, PA 19403 www.reallysi.com
<http://www.reallysi.com>  | http://blog.reallysi.com
<http://blog.reallysi.com> | www.rsuitecms.com
<http://www.rsuitecms.com>


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php