[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. Cheers, E. ————— Eliot Kimber, Owner Contrext, LLC http://contrext.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]