Comment:
An obvious type of application dependent behaviour that still exist in
DIS 29500 are the socalled compatibility options, boolean values such as
defined in 2.15.3 (2.15.3.6/autoSpaceLikeWord95,
2.15.3.26/footnoteLayoutLikeWW8, 2.15.3.31/lineWrapLikeWord6,
2.15.3.41/shapeLayoutLikeWW8, 2.15.3.51/suppressTopSpacingWP,
2.15.3.53/truncateFontHeightsLikeWP6, 2.15.3.54/uiCompat97To2003,
2.15.3.63/useWord2002TableStyleRules,
2.15.3.64/useWord97LineBreakRules, 2.15.3.65/wpJustification,
2.15.3.66/wpSpaceWidth etc).
As many alternative and conformant editors for Microsoft Office files
have existed in the better part of the last two decades these have
produced billions of documents - examples that come to mind are
Wordperfect, StarOffice, GoBeProductive and OpenOffice etc. - their
idiosyncracies in rendering and behaviour have not been taken into
account and should be able to be added by other vendors than Microsoft.
These should be more clearly marked as deprecated and application
specific behaviour on the XML level.
Proposed change:
Said tags are fully application specific, undefined and the
support for features involved is both optional and deprecated. In order
to make this construction more flexible and equal to the interests of
competitors all of them should be moved under a single collective
namespace: historical. Since no detail is added to these booleans, they
can be replaced by their own name making the system simpler and fully
future compatible. New values can then be added by any producer dealing
with a conversion from any format to OOXML. This would look like so:
footnoteLayoutLikeWW8
footnoteLayoutLikeKOffice1.1
Alternatively the application specific behaviour feature of DIS
26300:2006 could be used:
false
As 'informational' tags referencing non-disclosed behaviour the tags are
in their current form only meaningfull to Microsoft and can thus be
removed from the official DIS 29500 mainstream and be moved to an
application specific tag. Some sort of collision mechanism for this type
of features would be handy, in case applications mess up.
------------------
Comment:
Related un(der)defined application (and even application version)
dependent behaviour can be found on page 2252 (footer says '1469') in
par. 2.15.3.54 uiCompat97To2003 (Disable Features Incompatible With
Earlier Word Processing Formats) the text merely states "Disable UI
functionality that is not compatible with Word97-2003".
Which functionality this is, is left undefined and therefore the
required behaviour cannot be met by any other producer than Microsoft.
The use of a boolean for such a complex issue is improper and not
futureproof. (editorial comment: the given example is the generic
template and does not refer to uiCompat97To2003). In fact the options
on many of the subparagraphs of section 2.15.3 (the socalled
compatibility options, such as 2.15.3.6/autoSpaceLikeWord95,
2.15.3.26/footnoteLayoutLikeWW8, 2.15.3.31/lineWrapLikeWord6,
2.15.3.41/shapeLayoutLikeWW8, 2.15.3.51/suppressTopSpacingWP,
2.15.3.53/truncateFontHeightsLikeWP6, 2.15.3.54/uiCompat97To2003,
2.15.3.63/useWord2002TableStyleRules,
2.15.3.64/useWord97LineBreakRules, 2.15.3.65/wpJustification,
2.15.3.66/wpSpaceWidth) should be tunable as they impact many different
aspects of objects and text behaviour. 'All or nothing' is a
undesirable conversion strategy. Note: the compatibility options are
also referred to in another comment.
On page 1978 ('1197') 2.15.1.47 forceUpgrade (Upgrade Document on Open)
is again application and version specific. It specifies that "the
contents of a document may be upgraded and that the resulting document
shall not have its functionality limited to only those functions
compatible with earlier word processing applications". However, the
exact 'upgrade' path (i.e. how the deprecated VML maps into DrawingML,
etc.) that will be followed is nowhere defined; the implicit assumption
is made that the Windows Office 2007 applications knows but there is
now way for the user to know what is does and how reliable this is -
nor does it allow competitors to produce the same behaviour. It again
refers the uiCompat97to2003 element (§2.15.3.54) and forces the removal
of all compatibility options (§2.15.3.9) on the document - inherently
defeating the purpose of having these (i.e. it would be better to
prescribe ignoring the compatibility options but maintaining them.
Solution: provide a detailed oversight what exact behaviour
forceUpgrade and uiCompat97To2003 will evoke and make this feature both
more insightful and more tunable for end users.
Note: apparently there is behaviour in DIS 29500 that cannot be
rendered correctly in the binary Microsoft Office Formats. This
behaviour is currently not marked as such.
--------------------------------
Comment:
Another type of dependent behaviour is DIS 29500 dependence on operating
system architecture. E.g. Clipboard Format Type defined in 6.4.3.1 (p.
5738, '4955) defines five different options, all of which are not
defined in the spec nor available to external parties in an equal way -
e.g. using either the proprietary and potentially IPR-encumbered
WMF/EMF containers or the Microsoft proprietary Bitmap graphic format:
6.4.3.1 ST_CF (Clipboard Format Type)
This simple type specifies the allowed clipboard formats.
This simple type's contents are a restriction of the XML Schema
string datatype. The following are possible enumeration values for
this type:
Enumeration Value Description:
* Bitmap (Bitmap) Bitmap.
* Pict (EMF) Enhanced metafile.
* PictOld (WMF) Windows metafile.
* PictPrint (Printer Picture) An image rendered using the default
printer's settings. This is typically of higher resolution and
scaled differently compared to a picture created for onscreen
rendering.
* PictScreen (Screen Picture EMF) An image rendered using screen
settings. This is typically lower resolution than an image created
for printing.
There are no options for using non-Microsoft formats w.r.t. the
clipboard.
Proposed change: use mimetypes instead of container formats to allow
other clipboard formats.