OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: MIssing @keyref on specializations of <ph>

The question was asked today on the DITA Users List about why <filepath>
doesn't allow @keyword, which of course, raises the larger question of are
there any specializations of <ph> that should allow @keyword that
currently do not. (Note that most, if not all, of these <ph>
specializations allow <keyword> in their content, which provides a way to
use @keyref to get the effective content of the element and all of these
elements allow @conkeyref.)

To help answer this question I've started building some XQuery
infrastructure for analyzing the RELAX NG grammars for questions like this
(I'm using eXist-db as my XQuery database).

I implemented a query that returns all specializations of <ph> and
indicates whether or not @keyref is allowed:

Highlight Domain:

b: Not Allowed
u: Not Allowed
i: Not Allowed
line-through: Not Allowed
overline: Not Allowed
tt: Not Allowed
sup: Not Allowed
sub: Not Allowed

Utlity Domain:

coords: Allowed
lcAreaCoords2: Allowed
lcAreaCoords: Allowed

Equation domain:

equation-inline: Not Allowed
equation-number: Not Allowed

Programming Domain:

codeph: Not Allowed
var: Not Allowed
synph: Not Allowed
oper: Not Allowed
delim: Not Allowed
sep: Not Allowed
repsep: Not Allowed

Software Domain:

msgph: Not Allowed
filepath: Not Allowed
userinput: Not Allowed
systemoutput: Not Allowed

UI Domain: 

uicontrol: Allowed
menucascade: Allowed

XNAL Domain:

organizationnamedetails: Allowed
organizationname: Allowed
addressdetails: Allowed
locality: Allowed
localityname: Allowed
administrativearea: Allowed
thoroughfare: Allowed
postalcode: Allowed
country: Allowed

Based on the question about <filepath>, I think the TC needs to address
the following questions:

1. Do any of the <ph> specializations that do not allow @keyref need to
have it added?

2. If so, should we do so in 1.3 (the implication being that such changes
would be bug fixes to correct oversights in DITA 1.2) or should we push it
off to 2.0? I'd be inclined to push this off unless we are sure that any
change really is a bug fix (pretty much the same discussion we had about
making @href optional on glossref).

Looking at the list generated above, there doesn't seem to be a complete
consistency in what does and doesn't allow @keyref. For example, the UI
domain elements do but the software domain elements do not. Ideally there
would be some general design principal we could cite to explain the
current implementation.


Eliot Kimber, Owner
Contrext, LLC

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]