Re: [dita] otherprops syntax - should we specify?

["W. Eliot Kimber" <ekimber@innodata-isogen.com>]

Michael Priestley wrote:

> Just wanted to start the discussion on the list. For background, take a 
> look at the conditional processing topic in the current draft of the spec.
> 
> In the conditional processing section, it says:
> 
> "Each attribute takes zero or more space-delimited string values."
> 
> Now, this is fine for semantically grouped values like those in the 
> product or audience attributes, but is inadequate for otherprops, which 
> might contain multiple semantic groupings. For example, otherprops might 
> take parenthetical groupings of values as well as directly contained 
> values. 

One way to approach this "other" requirement is to make "otherprops" not 
a list of values but a list of namespace-qualified attribute names that 
hold application-specific properties, e.g.:

<!ATTLIST topic
    wek:myprop1
       CDATA
       #IMPLIED
    wek:myprop2
       NMTOKENS
       #IMPLIED
    otherprops
       NMTOKENS
       #FIXED "wek:myprop1 wek:myprop2"
    xmlns:wek
       CDATA
       #FIXED "http://www.drmacro.com/namespace/ditaproperties";
 >

This avoids any need to have some sort of sophisticated syntax for 
otherprops. Generic applications can easily resolve the indirection to 
distinguish property attributes from other attributes. DITA could then 
either define what the syntax of all property attributes is or leave 
applications free to define their own syntaxes (although at that point 
you really want to have some sort of mechanism by which you can declare 
what the syntax is for your attribute, at which point you start to think 
that maybe using XSD data types would be the right thing to do here).

This approach can be further generalized by having *all* property 
attributes declared in this way so that generalized processors use a 
single, consistent mechanism for determining which attributes of a given 
element are in fact property attributes, with the priviso that the 
DITA-defined attribute names are fixed (in that you can't remap the 
DITA-defined names) in order to preserve the ability for naive 
processors to process all DITA constructs.

This approach can be even further generalized by using this basic 
mechanism for characterizing *all* attributes for which the basic 
XML-defined types (e.g., ID and IDREF(S)) are not sufficient to indicate 
their semantics.

Cheers,

Eliot

-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8122

ekimber@innodata-isogen.com
www.innodata-isogen.com