[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] otherprops syntax - should we specify?
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]