Next in thread → Next in month →

Re: [dita] RE: Issue #20 (was [dita] Really two issues?)

From
Dana Spradley <>
Date
2005-08-02T19:00:00+00:00
ID
Thread
Re: [dita] RE: Issue #20 (was [dita] Really two issues?)
MHonArc v2.5.0b2 -->

















dita message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: Re: [dita] RE: Issue #20 (was [dita] Really two issues?)




From: Dana Spradley <>
To: 
Date: Tue, 02 Aug 2005 11:59:39 -0700










Now that I understand the issue a bit more after
this morning's meeting, I agree with Paul - "So I thought that we were
just allowing the attribute set to be extensible (as it should be!)."


I know for a fact that if and when my people convert to DITA authoring,
we'll need some way to hang arbitrary attributes specific to our
application off established DITA elements. We don't care about loss on
round-tripping, since these attributes are very application specific.
And we'd prefer to avoid a full-blown customization just to make the
modest overrides in processing we need based on these attributes.


I don't think it's really fair to define this issue so narrowly now -
when a number of us understood it in the broader sense I've just
outlined.


What would be so bad about putting in an empty placeholder parameter
entity to allow adding arbitrary attributes to any element, with the
proviso that they will be ignored by standard processing and consigned
to oblivion upon generalization?



Paul Prescod wrote:


  
    ... The feature is specifically for adding new global attributes
Next in thread → Next in month →