"John L. Clark" wrote: > >> For example, Standard Edition no longer has >> restrictions in terms of schema: DTD, W3C XML >> Schema, RELAX NG schema and Schematron are all >> fully supported. > > This is a very nice piece of news; does this mean that the Standard > Edition is no longer restricted with respect to XML Namespace support? > If this is the case, then this is indeed quite a Christmas present to > XXE users. Another piece of news that you left out strongly tempers > my excitement, however. >
This simply means that Standard Edition fully supports DTD, W3C XML Schema, RELAX NG, Schematron (i.e. with no restrictions at all). XXE, whether Standard Edition or Professional Edition, has always fully supported XML namespaces. The fact that XXE is not namespace-aware when a document conforming to a *DTD* is being edited is a *design* *decision* which applies to both Standard Edition and Professional Edition. >> From your changes page: > > """ > * The following features are totally absent, which means that they > are not only > disabled, but also that you'll not find them in the menus, tool > bars and dialog > boxes of new Standard Edition: > > - Process commands (used to transform part or all of the document > being edited > using the integrated XSLT engine). > > This means that all "Convert Document" menus have disappeared from new > Standard Edition. > > This also means that the command line utility convertdoc, which > may be used > to execute process commands outside XXE (useful in scripts and > makefiles), > will not work. > """ > > This is a very serious regression, We think that the real regression for the vast majority of end users is that the "Convert Document|Convert to HTML" menu item, which used to work in Pre-3.5.1 Standard Edition, has now disappeared. > and I would like to register my > protest against the decision to make this very powerful feature a > Professional Edition-only tool. Naturally, when working with a > proprietary product such as XMLmind XML Editor, we, the community, do > not have any power over the growth and maintenance of such a product. > It is the responsibility of the community to recognize that just this > sort of significant regression can happen, but it is sad to think of > XXE, with its history of strong support of the authoring community in > general, should serve as a textbook example of the dangers of > proprietary software. > > In the past, XMLmind's decision to restrict features has been based on > whether those features allow XXE to be deeply integrated into a unique > workflow. Not really. It was (and it still is) technically possible to integrate Standard Edition to the information system of an enterprise. The restrictions were (and still are) essentially legal. We have always wanted Standard Edition to be a good, free of charge, well-supported, *pure* *authoring* *tool* for technical writers. We are convinced that Post-3.5.1 Standard Edition is a better pure authoring tool that Pre-3.5.1 Standard Edition. Remember that Pre-3.5.1 Standard Edition refused to open certain XML documents. This is no longer the case. > In the case of integrated XSLT processing, the integrated > conversion of documents from one format to another can obviously > position XXE as a powerful tool for deeply integrated data management > in an organization. However, even without this tool integrated into > XXE, it is easy to craft an XSLT pipeline using any number of tools > that can perform automated conversion on demand. That is, of course, > the whole point of an open standard. For large scale integration, > XXE's process commands don't even factor into the equation. > > As a result, I believe that this decision only hurts end users who use > integrated XSLT processing as an enhanced macro command facility, such > as for annotating all the members of a set of elements with a > particular attribute or for doing other intralanguage conversion that > requires far deeper logic than is easily available with the XXE macro > language. The process commands have served as an elegant extension to > XXE's macro system; they simply make it easier to use a particular XML > language, rather than making it easier to integrate XXE with a unique > workflow. > > All these arguments aside, Standard Edition users have come to rely on > commands that take advantage of process commands, and now they are > left without them. The vast majority of end users, even professional technical writers, doesn't know what is a macro command or a process command. They just want something that works out of the box. Disabling process commands is indeed very annoying for consultants or local gurus who customize Standard Editions on the behalf of ``normal'' end users. Disabling process commands has probably broken their carefully crafted custom configurations and we are sorry for that. Here's what to do in such case: [1] Process commands which are used in macros are ``not really process commands'' (I'm 99% sure of that). Consider replacing this kind of process commands by commands written in Java[tm]. --> If you and other local gurus want it, we can even implement in next version a native command (i.e. not a process command) called "transform" which can be used to very efficiently[*] transform in place part or all of the document being edited. [2] OR you may consider purchasing a number of XXE Professional Edition. [3] OR if you work for an OpenSource project or for a non-profit organization, simply ask us to donate a number of XXE Professional Edition. > Granted, they can use older versions of XXE, but > they are then forced to fall farther and farther behind with respect > to maintenance of the software and any other enhancements that will > surely come in the future. Obviously, anyone interested can invest in > the Professional Edition, but there will always be a large part of the > community - individuals interested in robust information management in > XML - for whom that is not a reasonable option. I respectfully ask > that you reconsider this decision. The "transform" command seems to be a good compromise. What do you think? If you like the idea, please help us specifying this command. -- [*] Works on the copy of the document which is loaded in memory. XSLT style sheet is always cached. There is no user feedback like in process commands.
