Three separate API additions have been added as "Addenda" to the original VSIPL spec:

1) VSIPL Interpolation API
2) VSIPL Permute API
3) VSIPL Sort API

Integrate all of those into the main structure of the specification.

The “Addenda” sections have been fully integrated verbatim into the structure of
the specification. They have become chapters 9 (“Interpolation”, page 478), 10
(“Permutation Functions”, page 492), and 11 (“Sort Functions”, page 501).

There are a few places where "VSIPL 1.0 compliance" is mentioned. This should presumably be "VSIPL 1.3 compliance" or "VSIPL 1.x compliance".

Page 27, section 3.2.1, item “Functionality”: “VSIPL 1.0” has been changed to
“VSIPL 1.4”. Likewise in Section 3.2.2, item “Arguments”.

There are three compliance points: the whole VSIPL specification, the Core profile (mars/12-02-07), and the Core lite profile (mars/12-02-08). All the information needed for a compliance section is present on page 1 (PDF page 23) and those two documents. If this specification had been written using the ISO/OMG document template, this is what it should contain. This is only a matter of presentation.

On page 2, a new section 1.4 titled “Conformance” has been introduced following
section 1.3 (“Functionality”), which includes what was previously the last
paragraph of section 1.3.

Although the paragraphs describing the D, T, and O template parameters
for Dense<> mention the default value, the paragraph for M does not; it
should do so.

Changed item 6.3.2/4 (page 32) to:
“M must be a map type with a default constructor. Its default value is the
Local_map type.”

p31 (PDF page 53) There's a font formatting error. The words "Solve a covariance linear system" should be in Times not Courier font.

Page 22, section 2.9.1.3: The above text has been properly reformatted as inline
comment (/.../) embedded into (sample) code.

Sections should ideally be numbered. See ISO/OMG specification template

The entire document has been reformatted after being transcribed from MS Word
to DocBook. Sections are now properly numbered

The code examples could usefully be provided as separate machine-readable files

All example code is in fact now provided as separate C source files.

The "normative references" section states, "References to “VSIPL” or the
“VSIPL specification” refer to the VSIPL 1.1 API." This needs to be
updated to 1.4.

The references have been updated to refer to the canonical OMG URL.
Changed item 1.2/3 (page 1) to:
“References to “VSIPL” or the “VSIPL specification” refer to the VSIPL
specification at http://www.omg.org/spec/VSIPL/”

These sections contain phrases like, "Note: This header file is usually
included in other header files so direct inclusion is rarely necessary."

This is non-normative, and because "usually" means "some implementations
may not do this", it is not helpful to users in writing
standard-conformant code. In fact, it encourages users to write
non-comforming code! These should be removed.

The following note has been removed from item 4/1 (page 11):
“[Note: This header file is usually included in other header files so direct inclusion
is rarely necessary.]”

Direct Data Access (DDA) provides the means to access block data via raw pointers, independent of how the block holds the data, and regardless of whether or not the block is bound to user-specified data or VSIPL data. This functionality provides for a more extensible math library by enabling the use of external library calls on user-specified blocks without releasing them, and on VSIPL blocks in general. This API is already incorporated into the VSIPL++ specification and should be incorporated into the VSIPL specification as well in order to bring the two specifications closer together.

Please note that this issue is similarly being tracked on the specification repository: https://github.com/vsip/specs/issues/8

Added a new DDA API to VSIPL (VSIPL, sections 2.5, 4)

The dda::Data template allows accessing a block with particular layout
requirements, and the user may leave some of those requirements
unspecified – which means that the implementation may decide which to
use based on the block's layout.

Right now there is no way to query the specific layout parameters that
resulted from the combination of the block's layout with the layout
requirements.

We should add a new Data::layout_type member type to address that.

Added the new (nested) type (VSIPL++, section 7.3.2).

In the SVD section, the minor section numbers start over with each new
function, such that there are multiple "8.7.1.1 Functionality" sections.

The same problem affects the QR section, and possibly others.

I trust that this will be fixed when the document is reformatted in
Docbook, but wanted to explicitly note it so that there's a record of
why the numbers will have changed.

This issue was addressed during the OMG transition (VSIPL 1.3). The issue was accidentally left open.
Disposition: Closed, no change

Please collect all conformance information from various locations in mars/12-03-09 into a single conformance statement in section 1.3 as discussed at the March 2012 AB meeting

The specification contains conformance criteria for (almost) each function
definition. It is therefore not feasible to move them all into a single section.
Instead, the existing conformance section has been amended with paragraphs
outlining these criteria generically, to help the reader find those conformance
points easily.
New items 1.3/1 and 1.3/2 (page 1):
1. Most functions in this specification are parametrized for the value-types
they operate on. The individual function specifications indicate which
value-types need to be supported in a compliant implementation.
2. Compliance criteria relating to the VSIPL++ Parallel specification are listed
in [dpp.oplevel]

Please update the inventory document (mars/12-03-12) to follow the URL naming and other conventions outlined in OMG document ab/07-06-01.

A new and conforming inventory document supersedes the original one.