General XMetaL Discussion

• kkerr January 3, 2011 at 3:53 pm

  5.1 -> 6 changes?

  January 3, 2011 at 3:53 pm

  Participants 2

  Replies 3

  Last Activity 12 years, 2 months ago

  At my work we use XMetaL Author 5.1.  I've been looking into the possibility of upgrading to the most recent version – 6.  I couldn't find a change log anywhere though, laying out the differences between 5.1 and 6.  What bugs are fixed, and what new features are there?

  Of interest specifically is 5.1's problem with large XML files.  We regularly get files over 5MB and occasionally over 40MB, which 5.1 just can't handle.  Is 6 better at handling these?

  Reply

  Derek Read January 3, 2011 at 10:20 pm

  Reply to: 5.1 -> 6 changes?

  January 3, 2011 at 10:20 pm

  Release Notes
  We issue release notes listing features as well as the most important bug fixes with each version of our software. You can also view copies of these files on the forum here: http://forums.xmetal.com/index.php/topic,108.0.html

  “Large” Files
  We have not made any specific changes for handling “large” files (in your case somewhere between 5MB and 40MB) with the release of XMetaL Author 6.0.

  The product essentially relies on there being enough memory available to do two things:
  1) Build a DOM (node tree) representation of the document.
  2) Build a visual representation of the document from the DOM (using CSS among other things).

  This is a general limitation of any XML authoring software with editing capabilities similar to XMetaL (an editable DOM needs to be created and the DOM needs to be rendered to the user). XMetaL does many other things besides just rendering the document and to some extent they might come into play (validation, etc) but these two are the main ones.

  As it stands today, given enough memory XMetaL should be able to open a file of any size. The main issue you are likely to have is that your document might take a long time to render before you can begin editing and you may not want to wait (essentially making the product unusable for you for files of this size).

  This is not something we plan to try to address directly, however, we will continue to add support for newer versions of Windows. As newer versions of Windows support faster CPUs, multiple CPUs, and larger amounts of directly addressable RAM that may help if you feel you must edit documents this large.

  A single 40MB file must contain [u]a lot[/u] of content. Sounds like an encyclopedia. No matter what it is I should think it could be organized into smaller, more manageable pieces.

  So, What Do People Do? (ie: What Can You Do?)
  People typically don't run into these types of problems because they are not working with files this large. They may be producing large documents (after transformation into HTML, PDF, etc) but they are editing more manageably-sized documents. Often this is because it is prescribed by the CMS system they have integrated XMetaL with, or because it is a DITA 'best practice', or because they are using some other schema (such as DocBook) and that community has given some general guidance on how to manage these things.

  Most widely-used document-centric XML schema have clearly defined methods (as part of their specs) for breaking documents up into smaller portions (chapters/sections for DocBook, topics for DITA, etc) and a means to reference and organize those smaller portions (books in DocBook, maps in DITA, etc). The W3C XML Recommendation itself also defines a way to reference files (external entity) for use with any XML document type.

  These portions (chapters/sections, topics, entities, etc) can then be combined during the publishing phase by an XML, XSLT, or similar processor with less memory and CPU overhead. Such processors are less memory intensive because they do not need to allow the user to interact directly with and modify a “live” DOM (and they also typically do not need to render the document on screen).

  What About Data-Centric XML?
  For portions of your final document that are data-centric (content that is probably most easily organized in a table structure: table>row>cell) it may make sense to use an editor designed and optimized for that specific purpose (examples would include Microsoft Excel or a database with some kind of front end). This data is then transformed to XML during the publishing phase and injected into the appropriate location while the rest of the output is being built, or it might also be transformed directly into the final format and included directly. It may also be the case that people working with the data may not need to author the rest of your XML content and vice versa (and so using different tools just makes the best sense).

  Other Thoughts
  There are also benefits to organizing your content into smaller portions that you may not currently be seeing (translation cost savings, content reuse, content management, workflow management, among others).

  Reply

  kkerr January 4, 2011 at 7:32 pm

  Reply to: 5.1 -> 6 changes?

  January 4, 2011 at 7:32 pm

  We've learned to work around the filesize restrictions we have, that wasn't so much the intent of this thread; I was just wondering if there been any changes to that capability and it sounds like there hasn't.  It's rare that we need to make changes to the document in its largest form, and we've been using other tools to do it.

  I suppose I should ask more specific questions:
  – Is there any change (API deprecation, etc.) from 5.1->5.5->6.0 that would make plugins written for 5.1 invalid/broken in 6.0 (or, have you heard of this happening)?  How easy is to to move from 5.1 to 6.0 and keep the same plugins? 

  – 5.1 has a problem saving large files that results in the large file (>5MB) getting overwritten with a 0KB file when saving fails due to memory constraints.  Has this bug been fixed in later releases (didn't see anything about it in the patch notes)?

  – 5.1 has a problem rendering very long lines (>50k characters) in plain text view. Lines of this size are shown as blank lines, but the content is still present just not displayed.  Has this issue been fixed?

  Reply

  Derek Read January 10, 2011 at 8:07 pm

  Reply to: 5.1 -> 6 changes?

  January 10, 2011 at 8:07 pm

  1. Our design philosophy is to keep the product backwards compatible with regard to customizations (CSS, CTM, MCR, etc that are associated with a particular DTD/XSD) and so, unless something has been accidentally broken, customizations created for previous versions should function in newer versions. We pay particular attention to APIs. We do not change their behavior but instead create entirely new APIs (that may have similar functionality to existing ones, in which case the name is sometimes similar — all of the various paste-related APIs are a good example).

  2. We have noted a similar sounding 0KB file issue. We were not aware of this issue until users on the forum asked about it recently (http://forums.xmetal.com/index.php/topic,694.0.html). It is likely to be addressed in our next release.

  3. This issue has not been fixed. Lines longer than 4077 characters will be rendered improperly in Plain Text view, though this does not affect the actual content of the file (provided you don't attempt to edit such lines and work with the document in Normal or Tags On view instead). The recommended solution for this is to configure pretty printing (which also makes editing in Plain Text view easier in general). Settings for Pretty Printing are configured in the CTM file.

  Reply

• Author
  Posts