ElementNaming: DIS 29500 follows no consistent principle for the naming of elements. While it abbreviates the element for "Use Complex Script Formatting on Run" to "cs" (Part 4, section 2.3.2.6), it also has the element "customXmlMoveFromRangeStart" (Part 4, section 2.13.5.9). This is not an isolated example. In the portion of the table of contents reproduced as Annex A, there are approximately 712 element names down to Part 4, section 2.15.3.67. Out of that total, some 575 have whole words in the element names, sometimes more than one. In other words, 80 of that portion of DIS 29500 does not name elements with any consistent abbreviation principle.
DIS 29500 should be edited with a consistent element naming philosophy. It can either choose to have meaningful names or semantically opaque ones but it should choose one or the other.
DIS 29500
ed/te
Proposed Disposition of DIS 29500 Comment US-0281 (Modified: 2008-01-04) Although human readability is a design goal of XML, the specific element names or attributes used within any markup language have always been open to debate since the creation of SGML or XML standards, with some designers preferring long names and other short names (for example SVG, HTML, MathML and many others). It is often seen as a question of personal preference instead of a technical issue, and we note that there is also an argument that opaque element names are less culturally biased. We believe that Office Open XML can be read by humans because it is XML-based. In the case of DIS 29500, the comments about element names have fallen into two general categories: element names are too terse, or element names are not consistent. The terseness of some of the element names, such as <c> for cells in SpreadsheetML, is based on specific performance concerns and performance optimizations. There are usage scenarios for DIS 29500 that including millions of repetitions of the same element within a document. Since implementers need to extract the XML files from the OPC package in order to further process them, these repetitions can have significant impact on document size, which increases storage requirements and also increases parsing and validation time. For these reasons, Ecma TC45 used very small element names for certain highly repetitive elements. Regarding consistency of element names, the standard provides already a lot of consistency across names but we agree that there is always room for improvement and there may be opportunities for further consolidation of element names. This should be taken up under future maintenance of the standard, as it requires compromise between many contradictory opinions. For example, some commenters on DIS 29500 would like to see long element names reduced in length through the application of a “consistent abbreviation principle”, while others would like to see abbreviated element names made longer to add clarifying text. (Example: a suggestion to rename scrgbClr to ScreenRGBColor.) Finally, we note that SC 34 is standardizing a technology, DSRL, which allows XML names to be dynamically updated to a user’s preferred language while maintaining validity to the underlying schema. We recommend future consideration of this technology for this issue. Similar Comments: CO-0237 , MY-0016 , NZ-0008 ,
While this comment might look like “just-fix-it”, or even fluff, really, it is a serious, and major objection. It should certainly be included on the agenda at the BRM to review the document and make sure that this issue has been resolved, otherwise it should be sent back for more editing.
It won’t be on the BRM.
It is a total non issue.
Whether or not it gets on the BRM agenda is up to Alex Brown. We are just highlighting the interesting and unique comments to make his agenda forming job a bit easier. Consistency in element naming probably isn’t the most important issue raised, but it is desirable to have a consistent naming convention, consistency helps developers guess what a tag name should be and look up the details in the right place.
Consistent element naming makes understanding the schemas easier, makes implementation easier and makes XPath operations, be they DOM searches or XSL patterns way way easier. It significantly improves the human readability/writeability of documents. And while that may not be viewed as important, think of how many people write HTML, or code to generate HTML.
If this is being marked as WONTFIX, then its possible that one more round of stabilisation/product release is needed before trying to standardise this format.