- From: W. Eliot Kimber <eliot@isogen.com>
- Date: Thu, 19 Jun 1997 12:34:16 -0700
- To: w3c-sgml-wg@w3.org
Eliot has also been addressing these issues over in his work with the Medical people, and sent me the following, which at his request, I'm passing on to the WG. -T. Eliot from here down: I've been silent on this issue (except for one post presenting my AF usage proposal) largely because I've been too busy with getting the HyTime standard out and client work to think about this very difficult issue. Here is my feeling at the moment [Tim, feel free to share the following as you see fit, including on the WG]: 1. Architectural forms do in fact solve most (if not all) of the name space problems. They do it in what I think is a pretty elegant way considering that they depend on existing SGML methods and limitations. They offer a number of advantages, not least of which is that the whole architectural tower rising over a document can be completely ignored by unaware processors. Combined with subdocuments, most (but not all) of the requirements I've seen coming out of the name space discussion can be satisfied. I know this in my heart and mind. Convincing others that this contention is true is difficult and time consuming, and I don't fault anyone for being initially daunted by the abstact and formal nature of the mechanism. I've made it my life's work to educate the world about these technologies, which are, at their core, fairly simple and natural to use. 2. There seems to be a legitimate requirement for direct schema munging of the sort reflected in most of the non-AF proposals I've seen. This has some qualities that AFs can't provide. It also has some drawbacks and limitations that AFs avoid. 3. I agree with David Durrand that the initial negative reaction to AFs is short sighted. However, I don't think it's because the people having the reaction don't know what they're doing. I think it's because they haven't had 15 years to wrestle with the problem. They are, by and large, short-term thinkers, for good or ill, with short-term requirements that need to be met. Proposals with a lot of conceptual overhead require time for reflection, time they don't have. Applying what they know from other domains is a sensible and natural reaction. While we might disagree with their technical solutions, there's no profit in simply naysaying them out of hand. 4. AFs and more direct name munging can be used together (the munged names are, after all, ultimately just element types, which can always be derived from architectures). I have a number of serious concerns with the various schema munging proposals, to the degree I've had time to think about them at all, in particular: 1. The requirement that all name spacing be exposed in the instance. I think this is ultimately self-defeating, because it builds in dependencies on document authors/generators that you don't have with AFs (at least with explicit DTDs). Semantic derivation can't be retrofitted onto documents without modifying the instances. 2. Multiple levels of derivation all take up space in the instance. With AFs, multiple levels of derivation are visible only to architectural processors. 3. Multiple inheritance is difficult or impossible. With architectures, multiple inheritance, both of the same element from forms in different architectures and of the same element from different forms in the same architecture, is possible (although this second case is non-obvious and a bit tricky, although inherent in the general architecture mechanism). 4. Addressing of elements may be significantly complicated, because there may be multiple ID or entity name spaces within a single instance. Not impossible to manage, just a complicating factor. Note, however, that HyTime's general name-based addressing facility is perfectly capable of dealing with such name spaces because the mechanism for defining name spaces is completely generalized. However, simple ID/IDREF may no longer be sufficient. 5. It seriously confuses the syntax/semantic issues that SGML (and HyTime) are careful to keep separate, primarily through the use of subdocuments to construct compound documents. However, from my experience in evaluating the Japanese proposal to WG8, it appears that all of the above concerns can be addressed by reasonable technical approaches. Therefore, it seems likely that a useful namespace approach that is consistent with existing SGML designs and design principles can be developed and probably should be. I'm certainly not competent to accept or reject any proposal at the moment. I don't think there's been nearly enough thought or experimentation yet and seriously doubt the ability to define a mechanism by YE97 that will stand the test of time. However, I wouldn't impede the development of approaches that didn't require egregious violation of SGML syntax rules--obviously the experimentation has to happen and I don't see why we shouldn't let the people with the requirements do it. I'm not so arrogant as to think that the SGML world can provide all the answers to these issues and I'm certainly willing to listen to and learn from people outside our little world. I know that advances in any well-entrenched discipline must come from outside. As for the issue of medical records, I just don't know the answer. My personal feeling is that we should explore the architectural approach until we break it. In the mean time, other name space approaches will have had time to mature. We should carefully capture our name space requirements so that we can inject them into the discussion in the most productive form possible (i.e., devoid of implementation suggestions). My confidence in the architectural mechanism makes me think that, as the name space issue is explored in more depth, people with both come to appreciate the benefits of architectures and better see the limitations of name munging approaches. I say, lead by example. If you build it, they will come.... Cheers, E.
Received on Thursday, 19 June 1997 15:36:28 UTC