Agenda Items: (Re)alignment

["Park Seth" <seth.park@freescale.com>]

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

1. 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?
2. Clarify relationship between the component specialization and "data domain" information standards (such as IP-XACT)
3. 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.

seth.park@freescale.com

512.895.2463