Alex Brown has provided two documents from the BRM on OOXML on his blog. He got them from the open collection of documents published by ISO, another resource for us. You'll find many other documents in that same collection. One of the documents Brown has provided is an edited version of the notes from the meeting [PDF]. Obviously, that isn't sufficient, since one has no way to know all that was edited out. The other is a list of the resolutions. Apart from wanting to see unexpurgated notes, and to listen to the audio reportedly made of the meeting, what is the most interesting from the documents, as Groklaw member PolR emailed me, is that even the edited notes confirm some details we've been reading. I think they also raise some procedural questions.
Here's what PolR noticed: What stands out is the story published by Rob Weir on the four proposals, leading to the ballot is correct. The form ballot shown by Greece's delegate Antonis Christofides is also accurate. Alex Brown lists the options presented to the delegates but does not list what is option 3, just saying that it received no significant support. He also does not list the original option 4, just that it was amended. From Rob Weir's The Art of Being Mugged we learn that it was: "Option 3: Neutral third-party (ITTF) decides which Ecma responses are accepted" and "Option 4: Voting (approve + disapprove) must be at least 9 votes. Abstentions not counted".
This ballot resulted into a resolution as follow:
Resolution 37 "Option 4 prime": The BRM decides to use the following form to decide, by majority
voting, on each disposition of comments proposed by the Editor ("Response") which has not been
explicitly accepted or rejected by the BRM in other ways (list enclosed). A simple majority of "Approved"s of the votes on that "Response" will be required to implement each Response; abstentions are not counted. In the event of a tie on a "Response", no editing instruction will result from
that "Response" results of the vote: 29 in favour; none against; two abstentions (DE, BE): so resolved.
The other thing that stands out is the option 1 to accept all dispositions and option 2 to reject them all have been discarded by lack of consensus. So we can say that Alex claims they have used a consensus rule to discard the requirement of consensus for changing the DIS. You can see the form ballot on page 5 of the resolutions document, along with the notes about switching to "simple majority": Resolution 37 “Option 4 prime”: The BRM decides to use the following form to decide, by majority voting, on each disposition of comments proposed by the Editor (“Response”) which has not been explicitly accepted or rejected by the BRM in other ways (list enclosed). A simple majority of “Approved”s of the votes on that “Response” will be required to implement each Response; abstentions are not counted. In the event of a tie on a “Response”, no editing instruction will result from that “Response” — results of the vote: 29 in favour; none against; two abstentions (DE, BE): so resolved. I think X marks the spot right there, where they may have run off the procedural rails. I have been unable to find anything from any Directive that would make a simple majority vote as they defined it the way to go or any evidence that rules can be invented midstream by NBs or that these four options are appropriate or the only choices to be presented. I'm still searching, of course, but making up rules on the fly is definitely drawing my eye. And you'll find the notes about deciding how to vote on pages 10 and 11 of the edited meeting notes, and there it's stated that "the Convenor presented four options". That would be Brown, and as I showed you the other day, he seemed to realize long before the BRM that there would be no time to cover all the resolutions unless something was done to put matters to a vote without discussion on each resolution. The availability of a form to distribute seems to me to confirm. So my question is, why not advise each NB in advance that this would be an issue, so folks could be prepared properly, if in fact NBs get to decide such things, which I doubt. It raises the question in my mind whether there were special detours and procedural favors designed to push this format forward when it otherwise would have died a natural death.
The question has to be, I think whether anyone with an agenda pushed simple majority as eventually defined because it was the only way to move the OOXML format onward as if it were succeeding. If you recall Weir told us in his article on The Art of Being Mugged: "We were told that these options are not in the Directives and that were are given these choices because ITTF 'needs to act in the best interests of the IEC'." So. That must be one part edited out of the edited meeting notes. I'm guessing the investigation into this whole process by the EU Commission will be looking into things like this, so I'm not overly worried, but I am disturbed and a bit shocked. How can NBs vote to establish a new process for the fast track in the middle of one? Did the NBs who were hurriedly voting have access to legal advice on the significance of their votes, for example? Is this normally what happens or was this specially conceived and implemented just for Microsoft's format? I think those are valid questions, and only the audio can establish the answers definitively. Update: I note that Brown indicated back in January, in a comment in answer to a question, that the FAQ's interpretations were done by ITTF. Also, he has edited that article, which I quoted in the Malaysia article, so that it now reads as follows: Now, paper balloting follows normal JTC 1 in-meeting rules:
In a meeting, except as otherwise specified in these directives, questions are decided by a majority of the votes cast at the meeting by P-members expressing either approval or disapproval. (9.1.4)
[Update 2008-03-06. This was the wrong clause. In-meeting Fast Track BRM voting is for resolving the comments of a constituency determined by the combined voting procedure (O-members + P-members) as per the JTC 1 Directives 9.5, and that is the understanding of the "normal JTC 1 procedures" in 13.8.] Uh huh. Editing after the fact. I am supposing that this means they don't intend to admit this thing was and is a mess. Rob Weir has an interesting article now, called "JTC1 Improv Comedy Theater", which points out that citing this clause, 9.5, can't be correct: This is absurd. First, the combined voting procedure is for letter ballots given to an NB, not for a BRM meeting vote by a delegation. Second, the BRM was not voting on an FDIS, DIS, FDAM, DAM or FDISP. We were voting on whether to include changes into a set of meeting resolutions. We were told repeatedly that the BRM could not take a position on the DIS. Finally, if combined voting procedures are read as applying to Fast Track, then they would also need to apply to PAS, since both PAS and Fast Track are DIS's. But as shown earlier, the PAS process explicitly calls for P-member majority voting according to 9.1.4.
One does not arrive at the voting rules of 9.5 by any straightforward reading of the Directives.
So again, repeating from JTC1 Directions 1.2:
These Directives shall be complied with in all respects and no deviations can be made without the consent of the Secretaries-General.
I wasn't in favor of having any batch ballot, because it violates the spirit of the consensus process, as defined in JTC1 Directives 1.2:
These Directives are inspired by the principle that the objective in the development of International Standards should be the achievement of consensus between those concerned rather than a decision based on counting votes.
[Note: Consensus is defined as general agreement, characterised by the absence of sustained opposition to substantial issues by any important part of the concerned interests and by a process that involves seeking to take into account the views of all parties concerned and to reconcile any conflicting arguments. Consensus need not imply unanimity. (ISO/IEC Guide 2:1996)]
To resort to "counting votes" on the vast majority of the technical issues of DIS 29500, without discussion or opportunity for objection, this is a failure of the JTC1 process. But if we are to have a vote at all, it must be done in accordance with the rules.
So, let's stop the nonsense. Let's quit the tortuous post facto reinterpretation of the rules. Let's recount and republish the results of the BRM and move on with the process. If JTC1 cannot consistently adhere to its own rules, then it should consider another line of business. [End update.] Someone just sent me, appropriately enough, these documents in ODF format, and after I do the HTML, I'd like to post them here in plain text so those who depend on readers can easily follow along as well and so that they become more easily searchable. If anyone could volunteer to do the HTML and the check on those documents, I'd appreciate the help. Just email me if you can, with a comment left so we don't duplicate effort. Thank you.
Here are the Resolutions, followed by the Edited Notes, as text, thanks to Groklaw member ausage:
**********************************
ISO/IEC JTC 1/SC 34
SC 34 N 989
ISO/IEC DIS 29500 BALLOT RESOLUTION MEETING
Geneva, 2008-02-25..29
RESOLUTIONS OF THE MEETING
GB 2008-03-01 18:20
Legend:
Red italics are used for Resolutions.
R mmmm =
Response “mmmm” contained in SC 34 N 980, i.e. a disposition of comments
proposed by the Editor of ISO/IEC DIS 29500.
The files referred to are available on the BRM web site, managed by the
ISO/IEC JTC 1/SC 34 Secretariat, or by default in a zip file available
from ITTF.
Resolution 1: The BRM approves the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/AU28-draft.htm
as a replacement for R 28
— so resolved.
Resolution 2: The BRM decides to accept the instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CA-0075_and_CA-0078_Accessibility_Annex_V2.doc
as a replacement for R 91; those in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CA-0072_Document_Navigation.doc
as an addendum to R 120, which is accepted; those in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CA-0073_Image_Maps.doc
as a replacement for R 121; those in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_NZ-0011_Table_Captions.doc
as a replacement for R 94; and those in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CA-0069_Labels.doc
as an addition to R 119, which is accepted
— so resolved.
Resolution 3: The BRM accepts the proposed response to BR-7 contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_BR-0007_Web_Browsers.doc
but with an addition which makes it clear that the list is open-ended and with a correct reference for each entry
— so resolved.
Resolution 4: The BRM accepts the proposed response to CZ-6 contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CZ-0006_ST_LangCode.doc
as a replacement for R 16, but with the following change: column 2 of the first table shall be headed “Description
(informative)”
— so resolved.
Resolution 5: The BRM accepts the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_FI-0010_measurements_v2.doc
with “informal” being replaced by “informative”, in replacement of R 364, R 19, R 705, R 362, R 620 and R 103
— so resolved.
Resolution 6: Additionally, the BRM accepts the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_FI-0010_percentages.doc
but with the following changes: throughout the text, add the specific Unicode value U+0025 for the percentage sign; and
1 / 6
gb/jtc1/ooxml/brm/BRM_resolutions.doc
change all ranges to use the English words “from x up to [and including] infinity”, “inclusive[ly]”/&lduo;exclusive[ly]” etc.
— so resolved.
KR objected to Resolution 6.
Decision: The BRM decided to retain the valIso, val, maxValIso, maxVal,
refreshedDate and refreshedDateIso attributes and mark val, maxVal,
refreshedDate “transitional”.
ZA and DE opposed the above decision.
Resolution 7: The BRM resolves to accept the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_DE-0028_dates_v9.doc
in replacement of R 18 and R 43, but with the following corrections: the words “ISO value” shall be replaced by the words
“ISO 8601 value”; page 9, line 24 shall be restored and line 23 shall be marked “transitional”; and
all changes as well as choices among alternatives rendered necessary by the Decision above shall be made
— results of the vote: 19 in favour; 3 against (EC, US, ZA); 9 abstentions (JP, KR, IE, AU, BR, CN, NL, MX and GR):
so resolved.
Resolution 8: In Part 4, 6.1.2.19, equationxml, p 4653, the Note shall reference “Recommendation
MathML version 2.0”, not “Working Draft specification”
— so resolved.
Resolution 9: The BRM resolves to accept the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_GR-0014_equationxml.doc
in replacement of R 80, but with the following change: the attribute proposed for removal shall be made into a
“transitional” attribute instead of being removed, with a note making clear that the new mechanism is preferred
— so resolved by consensus, with CZ, DE and JP dissenting.
Resolution 10: The BRM accepts R 92 and R 992 with the changes to these responses contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/CA_Conformance_Class_Proposa_Draft4.doc
— so resolved.
Resolution 11: The BRM decides to accept R 34 with the change contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/IE-0010r.doc
— so resolved.
Resolution 12: The BRM decides to accept the changes contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_IL-0023_bidirectional_annex.doc
in replacement of R 729
— so resolved.
Resolution 13: The BRM accepts the proposed response to JP-40 and JP-46 contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/JP-040_and_JP-046_OPC_Conformance_-_Revised_v3.doc,
in amendment of R 224 and R 211 which are otherwise accepted
— so resolved.
Resolution 14: The BRM accepts the editing instructions contained in the section “ECMA: Proposal
for Reorganizing DrawingML” of http://www.itscj.ipsj.or.jp/sc34/def/BRM/KR-18-24-DrawingML-ECMA.doc
— so resolved.
Resolution 15: The BRM accepts the editing instructions contained in the following three files:
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Part_1_of_5_Conformance.doc ,
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Part_5_of_5_Conformance.doc and
http://www.itscj.ipsj.or.jp/sc34/def/BRM/US-multi-part_proposal_final.doc; with the understanding
that the Scopes may be changed in a later Resolution, and the following changes: the proposed
Part 4 (Primer) and the Annex covering accessibility guidelines shall become Annexes of the new
Part 1; the following sentence shall be added after the sentence commencing “The Editor shall”:
“The Editor is instructed to use ISO conformance language, ‘shall’, ‘should’ etc., in all normative text”
— so resolved.
2 / 6
Resolutions of BRM 2008-02-25..29
Resolution 16: Remove “(all parts)” from any reference in the text to ISO/IEC 10646:2003:
so resolved.
Resolution 17: The BRM accepts the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_MX-0003_VML.doc,
as an amendment to R 92 in addition to those in Resolution 10
— so resolved.
Resolution 18: The BRM decides that a reference to the W3C “WAI” document on accessibility shall be inserted by the Editor
— so resolved.
Resolution 19: The BRM decides that the text “(from Microsoft Office 97 to Microsoft Office 2008
inclusive)” shall appear in Scope texts after the text “Microsoft Office applications”
— votes in favour: 17; against: 6; abstentions: 9;
so resolved.
Resolution 20: The BRM decides to accept the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/MulitPartAndScope.doc, ignoring everything after “Pro-
posed resolution”, and with the following additions: a forward pointer to any terms defined
elsewhere shall be used as necessary; and the text “(from Microsoft Office 97 to Microsoft Office 2008
inclusive)” shall appear after “Microsoft Office applications”
— so resolved.
FR objected to Resolution 20.
Resolution 21: The BRM decides to instruct the Editor to incorporate an informative specification of
the following, with a reference to it from the Scope:
- All XML elements which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
- All XML elements which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006
- All XML attributes which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
- All XML attributes which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006
- All enumeration values which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
- All enumeration values which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006
- All simple types which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
- All simple types which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006
— so resolved.
Resolution 22: The BRM decides that all examples throughout ISO/IEC DIS 29500 shall be
well-balanced XML feasibly valid to the normative schemas, taking account of ellipses which may be
used to shorten examples. The Editor is instructed to make these corrections, for checking by ITTF
— so resolved.
Resolution 23: The BRM accepts the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/PT-60A2.doc
as modifications to R 93, R 98, R 78, R 80, R 82 and R 100,
which are otherwise accepted except as modified in other Resolutions; with the
following changes: the MIME type of text shall be given as “text/plain” and the MIME type of HTML
shall be given as “text/html”; and “Open XML Math” shall be replaced with a reference to the
appropriate part of this specification
— so resolved.
CA and CZ objected to Resolution 23.
Resolution 24: The BRM accepts the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/PT-60B2.doc
— so resolved.
Resolution 25: The BRM decides to accept the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_0135_bitfields.doc
in place of R 135, replacing “deprecated” by “transitional”, and with the following addition:
The Editor shall ensure that all existing attributes defining the bitfields described above
shall be “transitional”
— so resolved.
3/ 6
Resolutions of BRM 2008-02-25..29
Resolution 26: The BRM decides to accept the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_US-0075_numbering.doc as a replacement for
R 65, replacing in lowerLetter and upperLetter descriptions the word “language” with “script” and
striking out the word “modern”
— so resolved.
Resolution 27: The BRM decides that ISO/IEC DIS 29500 shall be changed so that the XML schemas
are normative. The schemas shall be contained in a normative Annex and shall be line-numbered
— so resolved.
Resolution 28: The BRM decides that no part of the schemas shall be repeated normatively in the
body text. The body text shall refer to schema constructs by: Annex number, clause or subclause
number, and declaration name; and by the line number for convenience
— so resolved.
CA objected to Resolution 28.
Resolution 29: The BRM decides to accept the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CA-0064_escaped_characters.doc
in addition to R 84, which is otherwise accepted
— so resolved.
Resolution 30: The BRM decides to accept the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/CA-041_BR-043_Security_Descriptor.doc
in replacement of R 74, but changing maxOccurs of the securityDescriptor element from 255 to unbounded
— so resolved.
Resolution 31: The BRM decides to accept the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/CZ-0053-corrected.pdf
in replacement of R 41, and also to correct in the same way all other occurrences of UTF-16 in the
context of serializing Unicode strings for cryptographic operations
— so resolved.
Resolution 32: The BRM decides to accept1 the new text contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CZ-0053_hashing.doc
— so resolved.
Resolution 33: With respect to “compatibility settings” the BRM accepts the Editor’s proposed
editing instructions on this subject as captured by responses 122, 123, 124, 125, 126, 127, 128, 129,
130, 131, 132, 133 and 34, but additionally the Editor shall include a bi-directional cross-reference
between the legacy compatibility settings and the new compatibility settings element
— so resolved.
BR objected to Resolution 33.
Resolution 34: The BRM decides to accept the instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_FI-0006_repeated_complex_types.doc
as an addition to R 21 which is otherwise accepted
— so resolved.
Resolution 35: The BRM decides to accept the instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_DE-0150_alternative_format_import_part.doc
as a replacement for R 140, with the following changes: the MIME types shall be corrected as in
Resolution 23
— so resolved.
CZ objected to Resolution 35.
Resolution 36: The following responses are accepted and the corresponding editing instructions
are issued to the Editor with the additional instructions given at the end: 104, 171, 193, 197, 217,
218, 219, 242, 250, 253, 259, 260, 262, 275, 277, 278, 281, 297, 298, 314, 320, 321, 360, 367,
381, 382, 395, 398, 399, 400, 401, 404, 406, 407, 408, 420, 437, 442, 443, 446, 449, 451, 455,
1 Note possible interference with R 102.
4 / 6
Resolutions of BRM 2008-02-25..29
456, 457, 459, 460, 478, 487, 488, 496, 513, 518, 520, 523, 524, 525, 527, 528, 547, 549, 560,
561, 563, 565, 608, 611, 632, 637, 638, 639, 648, 649, 650, 651, 652, 653, 654, 655, 656, 657,
661, 662, 663, 664, 665, 666, 667, 668, 669, 670, 671, 672, 673, 674, 675, 677, 679, 680, 681,
682, 683, 684, 685, 686, 687, 688, 737, 739, 740, 768, 814, 825, 827, 851, 852, 868, 873, 881,
896, 912, 916, 919, 922, 941, 984. In R 651, “when” shall be deleted. In R 739 and R 768 the NB
proposed change shall be implemented. The change described in the NB proposed change in
R 768 shall also be made in 2.16.5.44 and 2.16.5.45. In R 941 only the change from “contain” to
“have” shall be made
— resolved by consensus with three NBs opposed: BR, MY, ZA.
Resolution 37 “Option 4 prime”: The BRM decides to use the following form to decide, by majority
voting, on each disposition of comments proposed by the Editor (“Response”) which has not been
explicitly accepted or rejected by the BRM in other ways (list enclosed). A simple majority of
“Approved”s of the votes on that “Response” will be required to implement each Response; absten-
tions are not counted. In the event of a tie on a “Response”, no editing instruction will result from
that “Response”
— results of the vote: 29 in favour; none against; two abstentions (DE, BE):
so resolved.
ISO/IEC DIS 29500 Ballot Resolution Meeting
== Voting Paper ==
National Bodies are requested to use this form to record their positions on proposed dispositions
by the Project Editor as recorded in N 980, in accord with the resolution passed by the meeting.
Note: decisions taken in meeting sessions which apply to proposed dispositions shall override any
results arrived at through counting National Body votes as registered using this form.
National Body _____________
We wish to record the following position for responses not otherwise decided upon in the
resolutions of the meeting.
Approve [ ] Disapprove [ ] Abstain [ ]
We do not wish to record any position [ ]
Exceptions
Exceptions to the above default position (if any) may be recorded in the following table. If no
default position is given above, the following are the votes we wish to submit.
Response Number
| Position
|
| Approve [ ] Disapprove [ ] Abstain [ ]
|
| Approve [ ] Disapprove [ ] Abstain [ ]
|
| Approve [ ] Disapprove [ ] Abstain [ ]
|
| Approve [ ] Disapprove [ ] Abstain [ ]
|
| Approve [ ] Disapprove [ ] Abstain [ ]
|
| Approve [ ] Disapprove [ ] Abstain [ ]
|
Responses decided upon in the BRM and therefore not subject to voting by the voting form:
9, 16, 18, 19, 21, 28, 30, 34, 41, 42, 43, 65, 74, 78, 80, 82, 84, 91, 92, 93, 94, 98, 100, 103, 104, 119, 120,
121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 140, 147, 171, 190, 193, 197,
211, 217, 218, 219, 224, 231, 242, 250, 253, 259, 260, 262, 275, 277, 278, 281, 297, 298, 314, 320, 321,
344, 360, 362, 364, 367, 381, 382, 395, 398, 399, 400, 401, 404, 406, 407, 408, 420, 437, 442, 443, 446,
449, 451, 455, 456, 457, 459, 460, 478, 487, 488, 496, 513, 518, 520, 523, 524, 525, 527, 528, 547, 549,
5 / 6
Resolutions of BRM 2008-02-25..29
560, 561, 563, 565, 608, 611, 620, 632, 634, 637, 638, 639, 648, 649, 650, 651, 652, 653, 654, 655, 656,
657, 661, 662, 663, 664, 665, 666, 667, 668, 669, 670, 671, 672, 673, 674, 675, 677, 679, 680, 681, 682,
683, 684, 685, 686, 687, 688, 701, 703, 705, 726, 729, 732, 736, 737, 739, 740, 768, 814, 825, 827, 851,
852, 868, 873, 881, 890, 896, 912, 916, 919, 922, 925, 941, 973, 984 and 992.
Resolution 38: The BRM accepts, as a modification to the relevant Responses 703, 701, 726, 732
and 736 respectively which are otherwise accepted, the editing instructions contained in the five
files:
http://www.itscj.ipsj.or.jp/sc34/def/BRM/IL-0001-Mati.doc,
http://www.itscj.ipsj.or.jp/sc34/def/BRM/IL-0004-Mati.doc,
http://www.itscj.ipsj.or.jp/sc34/def/BRM/IL-0019-Mati.doc,
http://www.itscj.ipsj.or.jp/sc34/def/BRM/IL-0027-Mati.doc and
http://www.itscj.ipsj.or.jp/sc34/def/BRM/IL-0031.doc,
with the following change: example 2.18.44 shall be updated in an identical manner to example 2.3.1.13
— so resolved.
Resolution 39: The BRM accepts R 344
— so resolved.
Resolution 40: The BRM accepts R 634 and the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_JP-0070.pdf
— so resolved.
Resolution 41: The BRM accepts R 147
— so resolved.
Resolution 42: The BRM accepts the editing instructions in the section “Option 2” contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/MY-0015-CEILING-Response-30-v9.pdf
as a replacement of R 30
— so resolved.
Resolution 43: The BRM accepts R 973, and the instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/MX-0001_ZIP_compression_Proposal.doc
as a replacement of R 231
— so resolved.
END
6 / 6
Resolutions of BRM 2008-02-25..29
**************************************
[Editor: Short blue lines have been added between entries in an attempt to
separate the issues for easier reading. These lines are not in the original
PDF and have been arbitrarily placed by the editor.]
ISO/IEC JTC 1/SC 34SC 34 N 990
ISO/IEC DIS 29500 BALLOT RESOLUTION MEETING
Geneva, 2008-02-25..29
EDITED NOTES OF THE MEETINGGB 2008-03-01 18:30
Legend:
Red italics are used for Resolutions.
CY-nnnn (where CY is a two-letter ISO country code) =
comment no. “nnnn” from country “CY” contained in SC 34 N 980.
R mmmm =
Response “mmmm” contained in SC 34 N 980, i.e. a disposition of
comments proposed by the Editor of ISO/IEC DIS 29500.
The day shown does not usually correspond to the day the Resolutions
were finally taken, but to the day the subject was first raised.
Monday 2008-02-25
Locale
AU-28 (R 28)
AU: Add a Locale attribute of ST type to the F element.
Ecma: list of enumerated values (for Locale attr.?).
Resolution 1: The BRM approves the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/AU28-draft.htm as a replacement for R 28
— so resolved.
BE: requests future convergence of all ISs in this area; no editing instruction for Edition 1.
CA-69 (R 119), 72 (R 120), 73 (R 121), 75 (R 91), 78
Accessibility for people with disabilities
Reference in R 91
Ecma: openxmldeveloper/../OpenXMLAccessibilityGuidelines.aspx, proposed for incorporation in
future maintenance
CA: has submitted 12 pp of comments to these “Guidelines”, the response to which has generated
more questions and comments from CA.
R 119 (CA-69), R 120 (CA-72), R 121 (CA-73): have generated/will generate proposed additions to
the “Guidelines”, which will be added before it is inserted into DIS.
Resolution 2: The BRM decides to accept the instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CA-0075_and_CA-0078_Accessibility_Annex_V2.doc
as a replacement for R 91; those in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CA-0072_Document_Navigation.doc
as an addendum to R 120, which is accepted; those in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CA-0073_Image_Maps.doc
as a replacement for R 121; those in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_NZ-0011_Table_Captions.doc
as a replacement for R 94; and those in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CA-0069_Labels.doc as an addition to R 119,
which is accepted
— so resolved.
1 / 12 gb/jtc1/ooxml/brm/BRM_edited_notes.doc
BR-7 (R 42), compatibility with browsers:
Resolution 3: The BRM accepts the proposed response to BR-7 contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_BR-0007_Web_Browsers.doc but with an
addition which makes it clear that the list is open-ended and with a correct reference for each entry
— so resolved.
CN, CI: no editing instructions; CL, CO, CR absent at that time.
CZ-6 (R 16)
Resolution 4: The BRM accepts the proposed response to CZ-6 contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CZ-0006_ST_LangCode.doc as a replacement
for R 16, but with the following change: column 2 of the first table shall be headed “Description
(informative)”
— so resolved.
The BRM decided that “the Legacy Language Identifier table shall be ‘transitional’.”
DK: no editing instructions beyond the Editor’s proposed resolutions of DK’s comments, which DK
finds satisfactory, and would recommend the BRM to resolve to accept them.
EC-1 (R 1009): will support any acceptable solution to the date problem.
Units of measurement
FI-10 (R 705)
Ecma: the goals of Edition 1 are satisfied by the granularity chosen; the improvement proposed
should be worked out thoroughly during maintenance.
Resolution 5: The BRM accepts the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_FI-0010_measurements_v2.doc with “informal”
being replaced by “informative”, in replacement of R 364, R 19, R 705, R 362, R 620 and R 103
— so resolved.
Resolution 6: Additionally, the BRM accepts the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_FI-0010_percentages.doc but with the following
changes: throughout the text, add the specific Unicode value U+0025 for the percentage sign; and
change all ranges to use the English words “from x up to [and including] infinity”,
“inclusive[ly]”/”exclusive[ly]” etc.
— so resolved.
KR objected to Resolution 6.
p. 9: 92.000 or the alternative, but not both.
FR: wishes a distinction to be made in the standard between specifications for new OOXML docs
and specifications for backwards compatibility [“deprecated”?], possibly by splitting into separate
parts.
DE-28 (R 18), 30 (R 43) and a number of other NB comments: dates
DE and a number of NBs propose to use only ISO 8601 format, with a simple flag concerning what
assumption about 1900 is implied (since only storage and not algorithmic treatment is concerned);
US and many other NBs believe that backwards compatibility should be in an annex and
deprecated; CH believes “ISO-8601-only” will not work because it is an oversimplification.
AU believes the ODF approach would be more effective.
2 / 12 Edited notes of BRM 2008-02-25..29
Decision: The BRM decided to retain the valIso, val, maxValIso,
maxVal, refreshedDate and refreshedDateIso attributes and mark val,
maxVal, refreshedDate “transitional”.
ZA and DE opposed the above decision.
Resolution 7: The BRM resolves to accept the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_DE-0028_dates_v9.doc in replacement of R 18
and R 43, but with the following corrections: the words “ISO value” shall be replaced by the words
“ISO 8601 value”; page 9, line 24 shall be restored and line 23 shall be marked “transitional”; and
all changes as well as choices among alternatives rendered necessary by the Decision above shall
be made — results of the vote: 19 in favour; 3 against (EC, US, ZA); 9 abstentions (JP, KR, IE, AU,
BR, CN, NL, MX and GR):
so resolved.
GR-14 (R 80)
Resolution 8: In Part 4, 6.1.2.19, equationxml, p 4653, the Note shall reference “Recommendation
MathML version 2.0”, not “Working Draft specification”
— so resolved.
Ecma: The whole escaping mechanism is deprecated within the VML section.
BR: existence of the future Annex to contain VML is not yet certain.
CN: believes that much that is deprecated is actually derived from actual (past) implementations,
and that the number of specifications which are deprecated should be limited.
GB: to improve the syntax as GR suggests may have knock-on effects which would cause damage.
Resolution 9: The BRM resolves to accept the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_GR-0014_equationxml.doc in replacement of R
80, but with the following change: the attribute proposed for removal shall be made into a
“transitional” attribute instead of being removed, with a note making clear that
the new mechanism is preferred
— so resolved
by consensus, with CZ, DE and JP dissenting.
IN-56 (R 472); see R 92:
Draft resolution (IN, BR): In R 92, p. 404, second para. of Proposed Disposition: accept the editing
instruction constituted by the sentence beginning “Accordingly” but replacing the parenthesis by
“(including those created by migrating existing binary documents)”
and the word “should” by “shall”.
Resolution 10: The BRM accepts R 92 and R 992 with the changes to these responses contained
in http://www.itscj.ipsj.or.jp/sc34/def/BRM/CA_Conformance_Class_Proposa_Draft4.doc
— so resolved.
Original CA proposal: “Deprecated” is renamed as “Class 2”, feature by feature.
In addition to all the conformance conditions not involving Class 2 features, the conformance clause is
modified so that a Class 1 conformant document shall only contain Class 1 features; a document containing
one or more Class 2 features is a Class 2 conformant document.
Ecma: the attempt to translate a document containing deprecated features, into one without them,
sometimes involves loss of information.
GB: A phased approach to the migration from deprecated features to the others is needed,
including the possibility to write documents with deprecated features.
DE: would favour this phased approach only for unmappable (i.e. not perfectly mappable) features.
AU: two conformance levels (two classes to which conformity may be claimed): full OOXML and
legacy OOXML?
3 / 12 Edited notes of BRM 2008-02-25..29
IN, BR, CA, US, IE and any others will consult to describe the different cases of “deprecated”, to try
and clarify the issues connected with legacy features. A draft resolution will be produced, for
decision later in the BRM.
IE-2 (dates), 4 (ST_LangCode), 9 (Deprecation): already decided for more discussion and
resolution later in the BRM.
IE-10 (R 34, Compatibility settings):
Draft resolution: An informative Annex giving references to all deprecated features, including
compatibility settings, will be inserted in the standard.
Draft resolution: The semantics for compatibility settings should be included in the body of
Word-ProcessingML.
IE proposal:
Draft Resolution: Accept R 34 with the deletion of the sentence: “In addition, we will remove each
of these settings (and all other application compatibility settings) from their current location in the
specification (Part 4, §2.15.3, pages 1,368-1,487), and place them into a new annex for
deprecated features” — rejected.
Resolution 11: The BRM decides to accept R 34 with the change contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/IE-0010r.doc
— so resolved.
IL-23 (R 729):
Previous resolution:
- p 1688, add to 1st bullet: Similarly, a run with rtl=0 shall not contain strong RTL characters
- p 1692 l 5: directionality → order
- p 1684, “bdo” → “dir” x 2 in box at top of page
- p 1692, l 4 of table: “bdo” → “dir”.
Resolution 12: The BRM decides to accept the changes contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_IL-0023_bidirectional_annex.doc in
replacement of R 729
— so resolved.
- Five terms to express “right-to-left” (to be supplied by IL);
replace by e.g. “rtlDisplay”
- p 1685 ff: ensure all features provided in x.2 to apply to x.3, x.4 and x.5 — to be decided on
Friday morning.
IT-2: would like to invite any NBs interested in this proposal to contact the IT delegation.
JP-40, 46:
Resolution 13: The BRM accepts the proposed response to JP-40 and JP-46 contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/JP-040_and_JP-046_OPC_Conformance_-_Revised_v3.doc,
in amendment of R 224 and R 211 which are otherwise accepted
— so resolved.
Previous draft: Accept the Conformance clause (clause 2) for Part 2 as specified in R 202 (DE-154)
and R 992 (JP-27,28,29) with the following two modifications:
- 4th para to be repeated for data streams, i.e. add the following paragraph: “A data stream is
defined to be of conformance class OPC if it satisfies all the conditions applicable to data
streams listed in this Part.”;
- in 4th para, add “applicable to applications” in the relevant place.
4 / 12 Edited notes of BRM 2008-02-25..29
KE: no editing.
KR-18 to 24: proposal to remove components and/or separate them into different parts:
Resolution 14: The BRM accepts the editing instructions contained in the section “ECMA: Proposal
for Reorganizing DrawingML” of
http://www.itscj.ipsj.or.jp/sc34/def/BRM/KR-18-24-DrawingML-ECMA.doc
— so resolved.
Resolution 15: The BRM accepts the editing instructions contained in the following three files:
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Part_1_of_5_Conformance.doc ,
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Part_5_of_5_Conformance.doc and
http://www.itscj.ipsj.or.jp/sc34/def/BRM/US-multi-part_proposal_final.doc; with the understanding
that the Scopes may be changed in a later Resolution, and the following changes: the proposed
Part 4 (Primer) and the Annex covering accessibility guidelines shall become Annexes of the new
Part 1; the following sentence shall be added after the sentence commencing “The Editor shall”:
“The Editor is instructed to use ISO conformance language, ‘shall’, ‘should’ etc., in all normative
text”
— so resolved.
CA:
Resolution 16: Remove “(all parts)” from any reference in the text to ISO/IEC 10646:2003:
so resolved.
MY-16: Names
No consensus emerged on the MY proposal; a reformulation by MY remained possible.
Tuesday 2008-02-26
MX-3 (R 857), MX-6 (R 92)
Part of “deprecate” discussion. All of VML will be displaced into a (normative) (“deprecated”) Annex.
Resolution 17: The BRM accepts the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_MX-0003_VML.doc, as an amendment to R 92
in addition to those in Resolution 10
— so resolved.
NL: no draft editing instructions or discussion points.
NZ-11 (R 94) Accessibility: five proposals.
Resolution 18: The BRM decides that a reference to the W3C “WAI” document on accessibility
shall be inserted by the Editor
— so resolved.
NO-1 (R 925), Scope
Draft resolution
Make the overall scope of ISO/IEC DIS 29500 the following:
“This International Standard defines a set of XML vocabularies for representing word-processing
documents, spreadsheets and presentations. The goal of this standard is to represent faithfully the
existing corpus of word-processing documents, spreadsheets and presentations that have been
produced by Microsoft Office applications. It also specifies requirements for consumers and
producers of Office Open XML.”
— result of the vote: for 10; against 13 — rejected.
5 / 12 Edited notes of BRM 2008-02-25..29
Resolution 19: The BRM decides that the text “(from Microsoft Office 97 to Microsoft Office 2008
inclusive)” shall appear in Scope texts after the text “Microsoft Office applications”
— votes in favour: 17; against: 6; abstentions: 9;
so resolved.
Resolution 20: The BRM decides to accept the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/MulitPartAndScope.doc, ignoring everything after
“Proposed resolution”, and with the following additions: a forward pointer to any terms defined
elsewhere shall be used as necessary; and the text “(from Microsoft Office 97 to Microsoft Office 2008
inclusive)” shall appear after “Microsoft Office applications”
— so resolved.
FR objected to Resolution 20.
It was previously proposed to replace the Scopes of the various parts by the relevant re-edited
versions of the following:
“This International Standard defines a set of XML vocabularies for representing word-processing
documents, spreadsheets and presentations. The goal of this standard is, on the one hand, to
represent faithfully the existing corpus of word-processing documents, spreadsheets and
presentations that have been [previously?] produced by Microsoft Office applications (from Microsoft Office
97 to Microsoft Office 2008 inclusive) and, on the other hand, to facilitate extensibility and
interoperability. It also specifies requirements for consumers and producers of Office
Open XML.”
Resolution 21: The BRM decides to instruct the Editor to incorporate an informative specification of
the following, with a reference to it from the Scope:
- All XML elements which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
- All XML elements which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006
- All XML attributes which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
- All XML attributes which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006
- All enumeration values which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
- All enumeration values which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006
- All simple types which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
- All simple types which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006
— so resolved.
PL-3 (R 190): errors in XML examples
UK: found many genuine errors (beyond ellipses and the fragment-ness of the examples), and are
willing to share the results of the software tool used to check XML.
Resolution 22: The BRM decides that all examples throughout ISO/IEC DIS 29500 shall be
well-balanced XML feasibly valid to the normative schemas, taking account of ellipses which may be
used to shorten examples. The Editor is instructed to make these corrections, for checking by
ITTF
— so resolved.
PT-60 (R 98):
Resolution 23: The BRM accepts the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/PT-60A2.doc as modifications to R 93, R 98, R 78, R 80,
R 82 and R 100, which are otherwise accepted except as modified in other Resolutions; with the
following changes: the MIME type of text shall be given as “text/plain” and the MIME type of HTML
shall be given as “text/html”; and “Open XML Math” shall be replaced
with a reference to the appropriate part of this specification
— so resolved.
CA and CZ objected to Resolution 23.
Resolution 24: The BRM accepts the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/PT-60B2.doc
— so resolved.
6 / 12 Edited notes of BRM 2008-02-25..29
ZA-6 (R 6)
Restructuring into parts (“deprecated”, Primer): there should be a clear Scope for any (new) Part
decided.
Ecma: R 6 gives a road map (overall architecture) of the Parts proposed.
ZA: believes R 6 is not precise enough and requests clear instructions to the Editor to be
generated. (The proposed treatment of the Primer is acceptable.)
US: is already working with BR, KR & Ecma on this problem, and would be glad to involve other
NBs: what new structure (Parts), ... .
AU: R 6 meets AU’s requirements already, and AU proposes to accept it (for now).
The BRM decided that ISO/IEC DIS 29500 would be split into multiple Parts (29500-1, 29500-2,
29500-3 etc.). Conformance criteria needed to be clearly stated for each Part.
BR objected to the above decision.
Proposed: The proposal in R 6 for 29500-1, 29500-2 and 29500-3 is accepted in principle. A
Resolution must be drafted to describe precisely what is in each Part (including the Primer,
“deprecated” features, conformance classes, etc.), and conformance must be clearly
stated for each Part.
CH-17 (R 43)
Dates settled in a previous Resolution.
GB-182 et al (R 135): bit masks for values.
Proposal: change from bit fields to XML elements, except for fonts (which follow the relevant ISO
standard).
DK: supports.
Resolution 25: The BRM decides to accept the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_0135_bitfields.doc in place of R 135, replacing
“deprecated” by “transitional”, and with the following addition: The Editor shall
ensure that all existing attributes defining the bitfields described above shall be
“transitional”
— so resolved.
US-75 (R 65): enumeration formats (Part 4):
Resolution 26: The BRM decides to accept the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_US-0075_numbering.doc as a replacement for
R 65, replacing in lowerLetter and upperLetter descriptions the word “language” with “script” and
striking out the word “modern”
— so resolved.
AU-12 (R 9):
The repetition of complex type declarations in Part 4 introduces errors and gives duplicate and
redundant normative text.
CA: some constraints may not be present elsewhere; even if they are, more work may be involved
in looking them up if they are not included in line.
Resolution 27: The BRM decides that ISO/IEC DIS 29500 shall be changed so that the XML
schemas are normative. The schemas shall be contained in a normative Annex and shall be
line-numbered
— so resolved.
Resolution 28: The BRM decides that no part of the schemas shall be repeated normatively in the
body text. The body text shall refer to schema constructs by: Annex number, clause or subclause
number, and declaration name; and by the line number for convenience
— so resolved.
7 / 12 Edited notes of BRM 2008-02-25..29
CA objected to Resolution 28.
Draft resolution: No part of the schemas shall be repeated in the body text — results of the vote: 7
for, 19 against — rejected.
IL: same applies to descriptions of complex types: will be dealt with when separately raised.
BE
CA-64 (R 84): non-XML characters
CA Proposal: inclusion of non-XML characters should be “deprecated” (or equivalent).
BR proposal: OPC should be only method used for binary encapsulation.
Ecma: agrees with BR; word “binary” should be deleted; only strings are intended. Agrees with CA
to “deprecate”.
CA: software can easily make sure that no such characters are written; future standard should
guarantee this.
Ecma will propose a definition of “new document”, as in “A new document shall not be
created using deprecated features; only revision of an existing document may do this.”
Resolution 29: The BRM decides to accept the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CA-0064_escaped_characters.doc in addition
to R 84, which is otherwise accepted
— so resolved.
BR-43 (R 74) (related to CA-41): securityDescriptor
Resolution 30: The BRM decides to accept the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/CA-041_BR-043_Security_Descriptor.doc in replacement
of R 74, but changing maxOccurs of the securityDescriptor element from 255 to unbounded
— so resolved.
CZ-53 (R 41)
Resolution 31: The BRM decides to accept the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/CZ-0053-corrected.pdf
in replacement of R 41, and also to correct in the same way all other occurrences of UTF-16 in the
context of serializing Unicode strings for cryptographic operations
— so resolved.
Resolution 32: The BRM decides to accept1 the new text contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CZ-0053_hashing.doc
— so resolved.
ZA: The hash algorithm should be improved in spite of the desire to guarantee backwards
compatibility.
DK, US: The hashes actually stored in legacy documents must be able to be dealt with in some
fashion.
CA: Any use of an unsatisfactory hash, including that stored in a legacy document, raises incorrect
expectations as to the document’s integrity, and so it should be omitted totally.
DK: It would be even worse if the spec mentioned nothing. Whether false expectations are set is
up to the application.
CA: With the two sets of attributes the following may be the correct solution: when there is no
algorithm name and the attributes are transitional ones, apply the legacy algorithm; if the attributes are
strict ones the algorithm name must be specified.
1 Note possible interference with R 102.
8 / 12 Edited notes of BRM 2008-02-25..29
US: Clarify strict vs. transitional; default hash; thoroughly check this redesign. The issue is not a
security one for the document (which is not protected), but only to protect the unencrypted version
of the password itself.
ZA, CA, DK, US will work on this, for possible solution before Friday 17:00.
DK
Resolution 33: With respect to “compatibility settings” the BRM accepts the Editor’s proposed
editing instructions on this subject as captured by responses 122, 123, 124, 125, 126, 127, 128, 129,
130, 131, 132, 133 and 34, but additionally the Editor shall include a bi-directional cross-reference
between the legacy compatibility settings and the new compatibility settings element
— so resolved.
BR objected to Resolution 33.
EC-1 Wishes to consider a text from GR on dates, and will work with GR off-line.
FI-6 (R 21)
R 21 raises a question on redundancy of complex type attribute descriptions.
Resolution 34: The BRM decides to accept the instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_FI-0006_repeated_complex_types.doc as an
addition to R 21 which is otherwise accepted
— so resolved.
FR has no items it wishes to have discussed currently.
DE-150 (R 140), 161
Ecma is willing to remove this feature.
Resolution 35: The BRM decides to accept the instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_DE-0150_alternative_format_import_part.doc
as a replacement for R 140, with the following changes: the MIME types shall be corrected as in
Resolution 23
— so resolved.
CZ objected to Resolution 35.
US: Delete lines 15-17 of page 28 of ISO/IEC DIS 29500 (Part 1, 11.3.1).
UK
GR-92 (R 93)
GR: extra functionality provided by OO Math Markup Language can better be implemented as a
separate namespace vocabulary in MathML, rather than as an incompatible self-contained
specification as is contained in ISO/IEC DIS 25900.
AU: elements not allowed by the schema being used are not possible in MathML v3 (schemas
specify the elements they will allow, and if this is a closed set — no wildcard — then foreign elements
will be illegal) [this was later contradicted].
Ecma: MathML is not designed to be extended (as confirmed by W3C), and the OOXML solution
was proposed for this reason.
9 / 12 Edited notes of BRM 2008-02-25..29
ZA: OO MML is a large innovation, so an approach such as that suggested by GR would have
merit.
CA: accessibility remains important, as much for OXML as for MathML, and CA is willing to work
with others to advance this in the future.
IN-51 (R 973)
Ref. to external web site: ISO/IEC JTC 1 Directives and ITTF policy cover this, and the required
specification will be and remain publicly available to users of International Standards.
IE-9 (R 92)
Continued compliance of legacy documents once future editions of OOXML are published (which
presumably lose “deprecated” features).
CA: has some text concerning conformance classes which will be proposed when ready.
US: the corpus using “deprecated” features will continue to exist, and will continue to be
conformant, because NBs will probably decide to retain the legacy features in future editions of ISO/IEC
29500.
MX: Legacy documents may be conformant to a specific part of 29500, which exists precisely to
cover the existing corpus before edition 1 of 29500.
Wednesday 2008-02-27
Editorial: list provided by the Convenor:
Resolution 36: The following responses are accepted and the corresponding editing instructions
are issued to the Editor with the additional instructions given at the end: 104, 171, 193, 197, 217,
218, 219, 242, 250, 253, 259, 260, 262, 275, 277, 278, 281, 297, 298, 314, 320, 321, 360, 367,
381, 382, 395, 398, 399, 400, 401, 404, 406, 407, 408, 420, 437, 442, 443, 446, 449, 451, 455,
456, 457, 459, 460, 478, 487, 488, 496, 513, 518, 520, 523, 524, 525, 527, 528, 547, 549, 560,
561, 563, 565, 608, 611, 632, 637, 638, 639, 648, 649, 650, 651, 652, 653, 654, 655, 656, 657,
661, 662, 663, 664, 665, 666, 667, 668, 669, 670, 671, 672, 673, 674, 675, 677, 679, 680, 681,
682, 683, 684, 685, 686, 687, 688, 737, 739, 740, 768, 814, 825, 827, 851, 852, 868, 873, 881,
896, 912, 916, 919, 922, 941, 984. In R 651, “when” shall be deleted. In R 739 and R 768 the NB
proposed change shall be implemented. The change described in the NB proposed change in
R 768 shall also be made in 2.16.5.44 and 2.16.5.45. In R 941 only the change from “contain” to
“have” shall be made —
resolved by consensus with three NBs opposed: BR, MY, ZA..
Three priority issues: dates; conformance classes incl. “deprecation”; restructuring
(linked to previous item).
Ecma update on ongoing tasks.
Discussion on possible treatment of all responses which will not have been discussed by the end
of the BRM: the Convenor presented four options.
Draft Resolution “Option 1”: The BRM decides to accept and implement all the dispositions of
comments proposed by the Editor (“Responses”) which have not been explicitly accepted or
rejected by the BRM in other ways (list enclosed) — no consensus.
Draft Resolution “Option 2”: The BRM decides to reject all the dispositions of comments proposed
by the Editor (“Responses”) which have not been explicitly accepted or rejected by the BRM in
other ways (list enclosed) — no consensus.
10 / 12 Edited notes of BRM 2008-02-25..29
Option 3 received no significant support.
Option 4 was modified in discussion (Option 4 prime):
Resolution 37 “Option 4 prime”: The BRM decides to use the following form to decide, by majority
voting, on each disposition of comments proposed by the Editor (“Response”) which has not been
explicitly accepted or rejected by the BRM in other ways (list enclosed). A simple majority
of “Approved”s of the votes on that “Response” will be required to implement
each Response; abstentions are not counted. In the event of a tie on a “Response”,
no editing instruction will result from
that “Response” — results of the vote: 29 in favour; none against; two abstentions
(DE, BE):
so resolved.
ISO/IEC DIS 29500 Ballot Resolution Meeting
== Voting Paper ==
National Bodies are requested to use this form to record their positions on proposed dispositions
by the Project Editor as recorded in N 980, in accord with the resolution passed by the meeting.
Note: decisions taken in meeting sessions which apply to proposed dispositions shall override any
results arrived at through counting National Body votes as registered using this form.
National Body __________
We wish to record the following position for responses not otherwise decided upon in the
resolutions of the meeting.
Approve [ ] Disapprove [ ] Abstain [ ]
We do not wish to record any position [ ]
Exceptions
Exceptions to the above default position (if any) may be recorded in the following table. If no
default position is given above, the following are the votes we wish to submit.
Response Number
| Position
|
| Approve [ ] Disapprove [ ] Abstain [ ]
|
| Approve [ ] Disapprove [ ] Abstain [ ]
|
| Approve [ ] Disapprove [ ] Abstain [ ]
|
| Approve [ ] Disapprove [ ] Abstain [ ]
|
| Approve [ ] Disapprove [ ] Abstain [ ]
|
| Approve [ ] Disapprove [ ] Abstain [ ]
|
Responses decided upon in the BRM and therefore not subject to voting by the voting form:
9, 16, 18, 19, 21, 28, 30, 34, 41, 42, 43, 65, 74, 78, 80, 82, 84, 91, 92, 93, 94, 98, 100, 103, 104, 119, 120,
121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 140, 147, 171, 190, 193, 197,
211, 217, 218, 219, 224, 231, 242, 250, 253, 259, 260, 262, 275, 277, 278, 281, 297, 298, 314, 320, 321,
344, 360, 362, 364, 367, 381, 382, 395, 398, 399, 400, 401, 404, 406, 407, 408, 420, 437, 442, 443, 446,
449, 451, 455, 456, 457, 459, 460, 478, 487, 488, 496, 513, 518, 520, 523, 524, 525, 527, 528, 547, 549,
560, 561, 563, 565, 608, 611, 620, 632, 634, 637, 638, 639, 648, 649, 650, 651, 652, 653, 654, 655, 656,
657, 661, 662, 663, 664, 665, 666, 667, 668, 669, 670, 671, 672, 673, 674, 675, 677, 679, 680, 681, 682,
683, 684, 685, 686, 687, 688, 701, 703, 705, 726, 729, 732, 736, 737, 739, 740, 768, 814, 825, 827, 851,
852, 868, 873, 881, 890, 896, 912, 916, 919, 922, 925, 941, 973, 984 and 992.
11 / 12 Edited notes of BRM 2008-02-25..29
Thursday 2008-02-28
Two rounds of review of all, and adoption of some, outstanding draft resolutions.
IL-31, IL-27, IL-4, IL-1, IL-19:
Resolution 38: The BRM accepts, as a modification to the relevant Responses 703, 701, 726, 732
and 736 respectively which are otherwise accepted, the editing instructions contained in the five
files:
http://www.itscj.ipsj.or.jp/sc34/def/BRM/IL-0001-Mati.doc,
http://www.itscj.ipsj.or.jp/sc34/def/BRM/IL-0004-Mati.doc,
http://www.itscj.ipsj.or.jp/sc34/def/BRM/IL-0019-Mati.doc,
http://www.itscj.ipsj.or.jp/sc34/def/BRM/IL-0027-Mati.doc and
http://www.itscj.ipsj.or.jp/sc34/def/BRM/IL-0031.doc, with the following change: example 2.18.44
shall be updated in an identical manner to example 2.3.1.13
— so resolved.
IT: on a BE comment (R 44): proposal to come.
JP:
Resolution 39: The BRM accepts R 344
— so resolved.
R 229, R 634 — JP & Ecma
Resolution 40: The BRM accepts R 634 and the editing instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_JP-0070.pdf
— so resolved.
CL-108 (R 147): How many /e switches are allowed? Arbitrarily many (like all switches).
Resolution 41: The BRM accepts R 147
— so resolved.
MY-15 (R 30)
Resolution 42: The BRM accepts the editing instructions in the section “Option 2” contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/MY-0015-CEILING-Response-30-v9.pdf as a replacement
of R 30
— so resolved.
MX-1 (R 231)
Resolution 43: The BRM accepts R 973, and the instructions contained in
http://www.itscj.ipsj.or.jp/sc34/def/BRM/MX-0001_ZIP_compression_Proposal.doc as a
replacement of R 231
— so resolved.
NL: none to discuss.
NZ-6, NZ-12, NZ-14, NZ-15, NZ-52: document provided on Thursday; resolved elsewhere.
NO:
R 425, R 624, R 977: object linking.
Draft Resolution: The BRM accepts R 425, R 624, R 977 — was intended to be decided on Friday.
Friday 2008-02-29
Discussions and approval/rejection of various draft resolutions.
END
12 / 12 Edited notes of BRM 2008-02-25..29
|