RE: [dita] DITA Technical Committee Meeting Minutes: 22 February 2011

["Grosso, Paul" <pgrosso@ptc.com>]

> -----Original Message-----
> From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com]
> Sent: Tuesday, 2011 February 22 11:54
> To: dita
> Subject: [dita] DITA Technical Committee Meeting Minutes: 22 February
> 2011
> 

> The DITA Technical Committee met on Tuesday, 22 February 2011 at
> 08:00am PT for 18 minutes.

Not important, but we met for more like 55 minutes.

> 
> 
> 3. ITEM: Key resolution for complex <topicmeta> content
> 
> . . .
>
> Don: if we say that the element will be stripped, does that preclude
> the vendor from adding more later if an improved solution is made
> available. Bruce: How about hiding the markup rather than stripping
it.
> Robert: Yes, that's what I would prefer. And I would prefer that we
> simply allow rather than mandate that behavior.

I remember Robert saying in his email that he'd prefer to do
the XSLT-equivalent of string(.) which would remove the markup
but not the content of descendants.

But I don't remember (though I may have spaced out) talking about
hiding markup rather than stripping it, and I don't understand
what that means.

> 
> 9. NEW ITEM: PDF processing for files containing multiple topics
> 
> . . .
>
> CLOSED unless and until revived in future discussion.

We may have decided to close this item, but I don't think
it's a smart idea to close any item where the spec is confusing.
I'd rather add this to a list of things we need to clarify
in dita 1.3.

> 
> 11. CONTINUING ITEM: Perceptions that DITA is complex

What with all this discussion about how keys and key references
work--not to mention the other recent topics of discussion--among 
the smart, well-informed members of this TC, I cannot help but 
connect that to the discussion about the complexity of DITA. I'm 
not sure what the remedy is--perhaps the fact is that DITA is and 
has to be complex to do all we want it to do--but I don't see how 
any TC members can be surprised by the perception of complexity.

paul