It occurs to me that a "vehicle" in "systems" like DOM, XML and EDI can be rationally extended or is currently "utilizable" for significant added utility by some ability to "graft" "ordered tuples" "onto" "elements" and other structure/data objects. Further, that an ability to utilize such tuples should be "included" in any tree of structure at the highest level possible, and so augment their being invoked at any (lower only?) level in an "attached" manner at not only that level, but to one particular instance at such lower level. Thus, arrays like (element/whatever, alias, alias_index#, alias_rank_in_index#, value/content/whatever) and so on could allow/facilitate things like multi-lingualism, multi-version, multi-skill-level, elements's-access-control-list, etc. be achievable via a somewhat extension of core capability (even completely encapsule a systems structure whithin itself, and the ability to completely encapsule what can extensibly be done with it?). I must assume such function is already achievable via constructions from the existing systems mentioned above, but seems all that could be substantailly trivialized by an extensibility capability built in and available for utilization from whithin said systems at "core" levels. (It might lack some "obvious" "clarity", like "pointers" in "C" affect MANY). Does anyone follow this, particularly, has anyone implemented such functionality at maximally "low" levels of utilization of some such "system's" current "inner" capabilities? Instead of parallel trees of structure for structure_imposed and corresponding content-of-structure elements, just one structure. I don't think it would be efficient to start sending so much often unneeded data around, but "smart" implementations surely send only the data needed for that recipient at that moment, having "realized" the "parties'(tuples')" mutual overall data/traffic minimization needs and methods for achievement of same. I'm alluding to a really! simple and perhaps quite useful and very! small extension here. XML as a specific example; is this doable now, in XML/?, to achieve a major reduction of index overhead of parallel/related structure/data "content-(re/dis)assembly", let alone version control etc. overhead multiplying same??? Really smartly normalized dB tables formally and easily achieve this, but it's actually a LOT of work on a LOT of tables and a LOT of indexing. Can't all that be somehow "condensed" by adding "pointer arrays", "arrays of pointers", etc. capabilities? Naaaah. Regards, Jim Cunningham "If you can't remember it, ... ... ..., forget it." Firesign Theatre ------ XML/edi Group Discussion List ------ Homepage = http://www.XMLedi-Group.org Unsubscribe = send email to: [EMAIL PROTECTED] Leave the subject and body of the message blank Questions/requests: [EMAIL PROTECTED] To receive only one message per day (digest format) send the following message to [EMAIL PROTECTED], (leave the subject line blank) digest xmledi-group your-email-address To join the XML/edi Group complete the form located at: http://www.xmledi-group.org/xmledigroup/mail1.htm
