As I originally specified it, text is a specialization of ph so
it would not address the issue of ph not being allowed in some contexts where
PCDATA is allowed.
I think the solution there is simply to allow ph everywhere
PCDATA is allowed. I can’t think of any good reason it should be disallowed
anywhere.
Cheers,
E.
----
W. Eliot Kimber
Senior Solutions Architect
Really Strategies, Inc.
512 554 9368
From: Deborah_Pickett@moldflow.com
[mailto:Deborah_Pickett@moldflow.com]
Sent: Tuesday, August 14, 2007 9:11 PM
To: dita@lists.oasis-open.org
Subject: [dita] <text> element (#12020)
There was a bit
of conversation back in February (Eliot and Erik were contributors) about
a generic <text> element. Presumably, <text> is allowed
everywhere that PCDATA is allowed, and its content model is (PCDATA | text)*.
Eliot's message
(http://lists.oasis-open.org/archives/dita/200702/msg00064.html) comes up with
a justification for a base <text> element. That was in the context
of avoiding mixed content in conjunction with <data>. That's the
part that is linked to from Proposal #12020
(http://wiki.oasis-open.org/dita/DITA_Specification_1.2_Requirements).
But lately I've
seen other uses for a <text> element, if it existed. Conref of
snippets of text where <ph> is not allowed (such as in <keyword> or
<term> or <filepath>) is something that has popped up on dita-users
more than once, and something I've needed in my day job. Proposal #12035
(collation overrides) could probably benefit from it too.
Is this latter
use something that proposal #12020 is intended to cover?
--
Deborah Pickett
Information Architect, Moldflow Corporation, Melbourne
Deborah_Pickett@moldflow.com