The explanatory text mixes mentions of left margins and bottom margin. This not understood and might be an error, so that all referred margins should be left margins.
The text should clarify if the meaning of "left" is affected by possible specification of the bidiVisual element.
If not, this is a contradiction to the second paragraph of section 2.4.1 "bidiVisual (Visually Right to Left Table)" on page 281.
If yes, the name of this element should be changed to "lead".

Correct the use of "bottom" and replace with "left". Make it more clearly on how this works in RTL tables.

Change the name as appropriate.

"left (Table Cell Left Margin Default)"
, page 355 Section 2.4.26

te

Proposed Disposition of DIS 29500 Comment IL-0010 (Modified: 2008-01-03) The use of “bottom” in this text is indeed an error; the following changes will be made to Part 4, §2.4.26, page 355, lines 7­10: This element specifies the amount of space which shall be left between the left extent of the cell contents and the left border of all table cells within the parent table (or table row). This setting may be overridden by the table cell bottom left margin definition specified by the left element contained within the table cell’s properties (§ 2.4.26 2.4.25 ). As well, to resolve the second concern, the following text will be added to Part 4, §2.4.26, page 355, below line 10: For tables which have the bidiVisual property (§2.4.1) applied, this cell margin is applied to the right side of the cell. As well, use of the current element will be deprecated and replaced with a new directionally-neutral element named “start” with the same semantics. Accordingly, we will remove the left element from its current location in the specification (Part 4, §2.4.26, pages 355­356), and place it into a new annex for deprecated features. Following the precedent set by other ISO standards (such as SQL’s ISO 9075:2003 Part 1 and C++’s ISO/IEC 14882:1998), we will make use of a new Annex that contains normative descriptions of all deprecated features. The intent of this Annex is to enable a transitional period during which existing binary documents being migrated to DIS 29500 can make use of those deprecated features to preserve their fidelity, while noting that new documents should not use them. Accordingly, the Conformance clause will also be changed to state that newly created documents (those not created by migrating existing binary documents) should not use deprecated features. All deprecated features will be removed from their current locations in the standard, but will be fully defined in this new Annex.