[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [uoml-x-comment] Comments on the Public Review of UOML Part 1v1.0 Errata
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]