- From: DuCharme, Robert <DuCharmR@moodys.com>
- Date: Tue, 18 May 1999 08:43:59 -0400
- To: "'Noah_Mendelsohn/CAM/Lotus@lotus.com'" <Noah_Mendelsohn/CAM/Lotus@lotus.com>, DuCharmR@moodys.com, cowan@locke.ccil.org
- Cc: www-xml-schema-comments@w3.org
>Really terrific comments. Thanks! >(a) "export" is a natural counterpart to "import" This is true in the sense that importing is getting something from somewhere and exporting is sending something somewhere, but my point was that the Structures document doesn't use export that way. >(b) "export" has been used for more or less the same purpose >in describing other languages such as Modula-3 (and Pascal)... That's good enough for me. Like I said about other "technical" usages, a solid precedent is a good justification. >I think I was careful to use the word 'export' as a verb "Export" is fine as a noun (bourbon is a popular export of Kentucky) or as an adjective (export tariffs). >My personal preference would be to export nothing by >default, as it forces one to be explicit about interdependencies. I had thought about this, but didn't say anything because we want to let people create specialized versions of structures they didn't have a hand in creating. We can only push the Java/C++ analogies so far here, because the concept of an interface does not go along with information hiding in the XML case--you can't use something unless you have access to all the "source" code, so you can't say "here's the parts of my archetype that you can change, don't worry about the other parts" as you can when you distribute a binary class file and its documentation. So, if I design something that happens to almost suit the needs of someone I've never met who can get it off of my Web site, he or she should have the option of refining it in addition to copying and editing it. Bob DuCharme www.snee.com/bob <bob@ snee.com> "The elements be kind to thee, and make thy spirits all of comfort!" Anthony and Cleopatra, III ii
Received on Tuesday, 18 May 1999 08:36:26 UTC