RE: [dita] Attribute Generalization

[Michael Priestley <mpriestl@ca.ibm.com>]

Generalized values go in the props attribute,
and roughly correspond to the syntax already described for the otherprops
attribute.

Paul, I agree that it is simpler to
just ditch the promise (that generalized content can still be processed
in a specialized way) than to deliver on the promise. We've had this discussion
before, and I guess we'll keep having it. The current form of the proposal
already reflects a compromise between your views and mine, as well as input
from others. If you want to reopen the full debate, I guess we will - but
my position hasn't changed, and I consider this a core promise for the
architecture, and worth defending, even if it means delaying the entire
feature.

As a reminder, the rationale for specialized
processing of generalized content has to do with sharing content between
systems and organizations that may include a mix of specialization-aware
and specialization-unaware processing. This is not a hypothetical situation,
it's one we already have in IBM, and it's one of the promises that make
DITA robust enough to deliver cross-enterprise and cross-organization content
sharing.

Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25

"Paul Prescod" <paul.prescod@blastradius.com>

04/18/2006 09:53 AM

To	"Esrig, Bruce \(Bruce\)" <esrig@lucent.com>
cc	<dita@lists.oasis-open.org>
Subject	RE: [dita] Attribute Generalization

> From: Esrig, Bruce (Bruce) [mailto:esrig@lucent.com]
> Sent: Tuesday, April 18, 2006 6:43 AM
> Subject: RE: [dita] Attribute Generalization
> 
> Although it would make it more difficult to support DITA, I 
> have a conflicting urge, which is to allow even more 
> expressive power ...
> 
> props="proglanguage(Java) audience(CompanyA(student) 
> CompanyB(teacher))"

But what does that mean? Just the same as:

proglanguage="java" audience="student teacher"

Or 

proglanguage="java" CompanyA="student" CompanyB="teacher"

Or something else altogether?

> A compromise would be to put declarations of attributes into 
> the props attribute, and then have processors that support 
> extensibility look in those attributes for the values.

I think that according to the proposal, declarations go in the domains
attribute.

 Paul Prescod