Agenda Items: (Re)alignment

Hello 
Folks.

 

I'd like to propose 
that we spend some time on our call this week discussing alignment issues. 

 

Alignment of 
Component Specialization Purpose

  
Re-visit the 
  purpose of the component specialization. Are we simply trying to provide the 
  necessary semantics to capture register information consistently? Or are there 
  other processing scenarios that require a more robust data 
  model?

  
Clarify 
  relationship between the component specialization and "data domain" 
  information standards (such as IP-XACT)

  
Plan to modify the 
  component specialization per the results of the first two 
  topics.

To assist this 
discussion, perhaps we could walk through the spreadsheet and determine whether 
the information in each element:

  
appears in 
  documentation,

  
influences the way 
  other information appears in documentation or

  
provides a data 
  point that will assist in processing, storing, or retrieving data for 
  documentation purposes.

If the answer is 
"no", then I recommend we deprecate the element.

 

 

Alignment 
with SPIRIT

We started this 
trying to be as agnostic as possible to the work from other groups, but perhaps 
we should do more to formally align?

 

The work of the 
component specialization helps users get semantic richness NOW, without having a 
global XML strategy for IP data. As a plugin, it is a valuable (and viable) path 
from presentational markup to semantic richness that interoperates within the 
DITA architecture with NO special knowledge required.

 

But there is another 
opportunity for us to exercise our expertise...

 

I spoke last week 
with Gary Delp, Greg Ehmann, and Will Adams of the SPIRIT Register Description 
Work Group (RDWG). As you might know, IP-XACT has a weakness with "description" 
elements. Wherever this element is used (to describe a component, register, 
bitfield, etc.), it allows only a character data string. The RDWG has seen a 
couple of proposals for how to integrate more robust "documentation" support for 
these "description" elements for the next release of IP-XACT. 

 

So, what could our 
role be? It might be as simple as providing a linking recommendation. It might 
be as sophisticated as using the configuration file which integrates 
configurable IP into a "configured" module on a design component... and using 
that data to "configure" documentation information (leveraging specialized DITA 
select attributes?).

 

How much of this 
effort CAN and SHOULD we take on? Given our resource issues, will it kill our 
progress if we open ourselves to this issue? Perhaps there are OASIS rules 
against this sort of activity?

 

I'd like to hear 
what you think.

 

 

-seth

--------------------------------------------

seth park

information architect

Freescale Semiconductor, 
Inc.



512.895.2463