In VSIPL 1.3 (VSIPL before OMG) there is a get attribute function defined for SVD's. The function definition seems to be missing from VSIPL 1.4 (although the function is mentioned throughout the spec). This appears to be an editing omission during translation of 1.3 to 1.4.

Added the original text from VSIPL 1.3 (VSIPL, section 9.7.4)

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.]”

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.