Re: [uoml-x-comment] Comments on the Public Review of UOML Part 1v1.0 Errata

[mpsuzuki@hiroshima-u.ac.jp]

I'm sorry, I had mistaken the word "substantive".
I meant I found 3 substantive changes in addition to
Martin's list of substantive changes.

Here is corrected comment.

Regards,
suzuki toshiya



In addition to the substantive change found by Martin,
I found 3 substantive changes.
-------------------------------------------------------
change labelled 10 (Normative Reference)

[BMP] reference is invalid.
The referenced web page in MSDN does not define the file
format for the file suffixed with .BMP.

[RGB] reference is invalid.
The referenced standard is the standard for managed color
space. It introduces the restriction that revised UOML
should handle the color data in sRGB managed color space.
However, UOML cannot include color profiling data, and
many file formats can lack color profiling data (or,
some file formats cannot include at all). Especially,
GET method can returns BMP only, and most BMP cannot
include color profile data.
Thus, existing UOML implementation cannot conform revised
spec. Existing UOML data cannot conform revised spec.
This is substantive change, so revised spec cannot
be OASIS standard.
--------------------------------------------------------
change labelled 27 (Layer)
The previous spec does not define the masking order of
the layers, but revised spec defines it. This is no-substantive
change, so revised spec cannot be OASIS standard.
--------------------------------------------------------
change labbelled 44 (DELETE)
The previous spec does not forbid to leave the item
numbers after the deletion of the item. In the revised spec,
the position numbers after the deleted item number are required
to be decreased, and the unused position number is forbidden.
This is no-substantive change, so revised spec cannot be
OASIS standard.
--------------------------------------------------------

Because substantive changes break OASIS standardization
process, I think the revised spec could not be OASIS standard,
so it could not be JTC1 standard either.

Restarting new spec from scratch (to avoid incompatibility
with previous revision) and provision it with referential
implementation under open license (to clarify underspecified
restrictions etc) would be better.

Regards,
suzuki toshiya