On 12/27/06, Hussein Shafie <hussein at xmlmind.com> wrote:
> XMLmind XML Editor Standard Edition 3.5.1 can be downloaded from
> http://www.xmlmind.com/xmleditor/download.shtml
>
> v3.5.1 (December 27, 2006):
>
> * The differences between Standard Edition and
> Professional Edition have radically changed.
Indeed they have.
> 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.
>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, 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. 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. 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.
Sincerely,
John L. Clark
--
PLEASE NOTE that this message is not digitally signed. As a result,
you have no strong evidence that this message was actually sent by me.
Upon request I can provide a digitally signed receipt for this
message or other evidence validating its contents if you need such
evidence.
