XML Valuetype Language Mapping Avatar
  1. OMG Specification

XML Valuetype Language Mapping — Open Issues

  • Acronym: XML
  • Issues Count: 1
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
XML12-1 B.1 value_dom.idl XML 1.1 open

Issues Descriptions

B.1 value_dom.idl

  • Key: XML12-1
  • Legacy Issue Number: 7991
  • Status: open  
  • Source: Connox ( Raf Schietekat)
  • Summary:

    Several member values are redundant: Node.s_nodeName_key, Element.s_tagName_key and Attr.s_name_key; Attr.s_value and its children; Document.s_documentElement and its children. This is already bad enough, maybe there are more. The redundancy is bad, but if we're stuck with it, how is it to be managed, what invariants are to be observed? Another issue is the strange types of DocumentMetadata's members. I can understand a StringFlyweight node_name_map (it's quite an infrastructure to do something that valuetypes do out of the box, but maybe it is more efficient, I don't know without testing, and this is not my problem). But why are there element_name_map and attr_name_map members, and why are some of these NameValueFlyweights? Is that the same as the redundancy described above (that's quite a load on the network this time)? And what's the use of NameValueFlyweight? Why does it have a get_value_by_key_count() operation? It's not described in the document, and it makes no sense for me. Is this specification really being used?

  • Reported: XML 1.1 — Sat, 18 Dec 2004 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT