Hi, We just uploaded oXygen 11 beta, scroll down for the installation kits [1] and for a license key for tests [2]. I hope you will enjoy getting early access to the new version 11 features :). We expect to release version 11 in the first part of October. Here it is a list with the most important changes: XProc support ============= The XProc support includes editing, validation and execution through XProc scenarios. oXygen bundles Calabash as built in engine but additional custom XProc processors can also be configured. The Author mode presents a nice visual rendering of the XProc scripts. XSLT documentation ================== oXygen generates documentation for XSLT stylesheets in XHTML format by inspecting the stylesheets and determining what components they contain and where they are used. User supplied description can be specified either in the form of XML comments or in a simple language for which oXygen provides easy editing support though special actions for inserting documentation and through content completion. User defined documentation languages can also be used but the rendering stylesheets need to be updated to handle their conversion to XHTML. XQuery Debugger for the Berkeley DB XML database ================================================ The debugging interface of Berkeley DB 2.5 database was integrated with the XQuery Debugger of oXygen. EMC Documentum integration ========================== oXygen XML Editor integration with Documentum is built on top of DFS 6.5 and includes: * Repository browsing * Check-out and check-in * Transparent resource access (open, edit, save) * Import/export * Resource management (create, delete, copy, move) * etc. A video demonstration showing that in action is available at http://www.oxygenxml.com/update/Documentum/oXygenDocumentum.html More details for setting up the connection to Documentum can be read here https://community.emc.com/thread/4519 More flexible transformation and validation scenarios ===================================================== There is no more a dependence btween the currently edited file and the scenarios available for transformation or validation, thus users can apply any transformation or validation scenario on any file. More, the project view allows to associate scenarios on a folder or on the selected files. Updated Saxon to version 9.2 ============================ Saxon 9 SA was updated to the latest version Saxon 9.2 Enterprise Edition. oXygen supports also Saxon 9.2 Professional Edition and Home Edition. Update oNVDL to jing-trang ========================== The NVDL implementation from oNVDL was moved to jing-trang and was updated to use the latest jing-tarang version 20090818. Improved Author editing interface for non technical users ========================================================= The Author mode has new location tooltips and current element highlights that help the user to identify the position in the edited document. By default it turns on a more constrained editing mode that avoids for instance inserting text in the elements that do not allow text nodes or inserting elements not allowed by the schema. Render and visually edit MathML in the Author mode ================================================== MathML notations are rendered and can be edited in Author mode with a default editor or with an optional and more powerful editor based on the MathFlow component from Design Science. Render MathML in the output of DocBook transformations ====================================================== MathML notations included in a DocBook documents are rendered as graphic notations in the PDF and XHTML outputs of the DocBook transformations. Integrated DITA OT 1.5 ====================== oXygen comes with version 1.5 (M19) of DITA OT which supports the DITA 1.2 specification. DITA 1.2 support ================ Some of the new DITA 1.2 features are supported. These include insertion and visualization in the Author mode of conref ranges and conkeyrefs, insertion and navigation for keyrefs in the context of the current DITA map. Spell checking on a set of files ================================ Spell checking can be applied with only one action on all the files in a folder from the Project view or on all the files referred by a DITA map from the DITA Maps Manager view. Automatic/Easy setup for AntennaHouse Formatter =============================================== An installation of the AntennaHouse FOP v4 or v5 can be automatically detected or easily configured for performing FO to PDF transformations and for DITA map transformations executed with DITA OT. Support for WMF images in the Author mode ========================================= WMF images can be rendered now in the Author mode. Allow more than one toolbar with custom actions in Author mode ============================================================== You can create up to 4 toolbars containing custom actions that will be available in the Author mode. Updated TEI schemas to version 1.4.1 ==================================== The latest version of TEI schemas were added. XPath content completion for Schematron ======================================= The content completion offers XPath 1.0 and XPath 2.0 functions and axes in attributes like report/@test, value-of/@select, etc when editing a Schematron schema. Support attributes in the XPath filter for Find/Replace ======================================================= The XPath filter of the Find/Replace dialog works also for an XPath expression that selects only attributes, thus it is possible to find/replace only in attribute values. Extended large documents editing support ======================================== Larger XML documents can be opened for editing, for example a 200MB document can be opened in oXygen using a 512 MB or more. oXygen will detect large documents and will automatically turn off or change the implementation for some editor functions to reduce the memory usage. Extended large documents viewing support (up to 10 GB) ====================================================== The large fie viewer can open files up to 10 GB in read only mode. WebDAV sources available in the Database Explorer view ====================================================== The files and folders available in a WebDAV source can be browsed and opened using the Database Explorer view. Digital signature without key info ================================== An XML document can be signed without including the key info in the signed document and the signature of a signed XML document that does not include key info can be verified. Resolve imported XML Schema location based on namespace ======================================================= The location of an XML Schema imported in other schema can be resolved with an XML catalog based only on the schema namespace when the schema location is not specified. [1] oXygen XML editor 11 beta installation kits: ================================================ Windows http://www.oxygenxml.com/update/beta11/Windows/VM/oxygen.exe MacOSX http://www.oxygenxml.com/update/beta11/MacOSX/oxygen.tar.gz Linux http://www.oxygenxml.com/update/beta11/Linux/VM/oxygen.sh Linux 64 http://www.oxygenxml.com/update/beta11/Linux64/VM/oxygen.sh All platforms http://www.oxygenxml.com/update/beta11/All/oxygen.tar.gz Test license key ================ --- start license key --- Registration_Name=beta tests Company= Category=Enterprise Component=XML-Editor, XSLT-Debugger, Saxon-SA Version=11 Number_of_Licenses=1 Date=09-15-2009 Trial=31 SGN=MCwCFAnAP2PY5IsEQ5Hdxfd8QNj78MszAhQtljiO5WRwo71r6e8f8Ex7NrS+BQ\=\= --- end license key --- Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com
On 9/16/09 10:56 AM, "George Cristian Bina" <george@oxygenxml.com> wrote:
Hi,
DITA 1.2 support ================ Some of the new DITA 1.2 features are supported. These include insertion and visualization in the Author mode of conref ranges and conkeyrefs, insertion and navigation for keyrefs in the context of the current DITA map.
From an integration API standpoint I would want to have a "key definition
Support for keyref very nice: the DITA 1.2 spec uses keyref heavily--nice to be able to navigate all the xrefs in the editor now! I notice that the insert keyref dialog only shows the keys descending from the map selected in the map manager. I'm not sure what else you can do, but I think I would like to have the option of setting a "keyref resolution context" for an editing session or a project, which would normally be the root map I'm working under. In the case of the DITA 1.2 spec, there is a root map and then a number of subordinate maps, each with its own set of key definitions specific to that map (e.g., one for the L&T module, one for the Machine Industry module, etc.). If I'm editing an L&T topic I may still need to refer to a base element's key, but to do that, I have to explicitly select the master map, not the L&T map (which is where I probably am if I've either opened that initially or navigated to it from the main map before navigating to the topic I want to edit). Not a deal killer, but it means you have to have the map open in order to select keys from it (of course, the editor will have to have processed the map in any case to make keys available, even if it doesn't show it in the map manager). I could see having the "default key context" be a project-level setting. On the other hand, in a large content set you might have 10s of thousands of keys organized into many submaps, so just presenting a flat list of keys will not always be practical. Might be useful to have a tree view of the keys reflecting their organization into maps and submaps. But in that scenario, I can see that showing only the keys in a specific map helps because it implicitly narrows the selection. In my map specializations I now include a generic "keyset" topicref that simply serves to organize sets of keys within a map. Might be useful to have a key selector reflect any topicref hierarchy and navigation titles used in the map, on the assumption that such groupings must be significant. provider" extension point so that a CMS could, for example, provide keys without the need to first open a map, so one could edit a topic from the CMS and still create key-based links to things the CMS knows about--I didn't look to see if such an API is already provided. Cheers, E. ---- Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc. email: ekimber@reallysi.com <mailto:ekimber@reallysi.com> office: 610.631.6770 | cell: 512.554.9368 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403 www.reallysi.com <http://www.reallysi.com> | http://blog.reallysi.com <http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>
Hi Eliot, See some answers below: ekimber wrote:
I notice that the insert keyref dialog only shows the keys descending from the map selected in the map manager. I'm not sure what else you can do, but I think I would like to have the option of setting a "keyref resolution context" for an editing session or a project, which would normally be the root map I'm working under.
In the case of the DITA 1.2 spec, there is a root map and then a number of subordinate maps, each with its own set of key definitions specific to that map (e.g., one for the L&T module, one for the Machine Industry module, etc.).
If I'm editing an L&T topic I may still need to refer to a base element's key, but to do that, I have to explicitly select the master map, not the L&T map (which is where I probably am if I've either opened that initially or navigated to it from the main map before navigating to the topic I want to edit). Not a deal killer, but it means you have to have the map open in order to select keys from it (of course, the editor will have to have processed the map in any case to make keys available, even if it doesn't show it in the map manager).
I could see having the "default key context" be a project-level setting.
We considered the adopted solution (using the current edited DITA Map as the context) as the easiest way to choose/resolve keyrefs without the need for additional configuration on the user part. Indeed in the case of maps which refer other maps it is not always a good solution and requires sometimes opening the master map just so that you can reference a key from its context. We'll try to come up with a way of being able to specify the master-map.
On the other hand, in a large content set you might have 10s of thousands of keys organized into many submaps, so just presenting a flat list of keys will not always be practical. Might be useful to have a tree view of the keys reflecting their organization into maps and submaps. But in that scenario, I can see that showing only the keys in a specific map helps because it implicitly narrows the selection.
The decision to have a flat representation of the list of keys was made because, if my interpretation of the DITA 1.2 is correct, keys can overwrite each other. If the layout has a tree structure maybe the user chooses a key from a sub-map believing it hrefs a location and in fact the key is overwritten in a parent map to point to another location. What do you think about this situation?
In my map specializations I now include a generic "keyset" topicref that simply serves to organize sets of keys within a map. Might be useful to have a key selector reflect any topicref hierarchy and navigation titles used in the map, on the assumption that such groupings must be significant.
Yes, indeed a problem with the flat selector. Maybe a tree table with a third "Navtitle" column would be better.
From an integration API standpoint I would want to have a "key definition provider" extension point so that a CMS could, for example, provide keys without the need to first open a map, so one could edit a topic from the CMS and still create key-based links to things the CMS knows about--I didn't look to see if such an API is already provided.
We have no such thing in the API, yet but it will be discussed.
Cheers,
E.
---- Eliot
Regards, Radu -- Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com
You are correct that a given key definition may be overridden by an earlier definition in the map hierarchy, which is why you must establish a root map context before you can resolve any key. A key selector must reflect the *effective* key set, not the literal set of key definitions in a source map. For that reason, my suggestion to use the topicref hierarchy in the original map to guide a selector dialog is probably a bad idea upon reflection: it would be difficult, if not impossible, to generate a coherent tree of effective key definitions when they are pulled from many different maps. So forget that. In light of that analysis, the only ways I can think of to sensibly group keys are: 1. Group by map, such that for each active key definition, you group it under the map in which it is defined. In this context you could, possibly, reflect its grouping within the map, but that might be too hard to do. 2. Group alphabetically by key. This would provide useful groupings but wouldn't necessarily address the issue of potentially very long lists of keys in large key sets. 3. Group alphabetically by key target navigation title. This has the same long list potential problem but might be a more meaningful organization of targets--there's no requirement that keys reflect the target's details in any way (keys might be generated as some sort of UUID in some situations). 4. Group by the storage organization of the targets (that is, their file system or CMS organization). This may or may not provide a better tree less likely to have very long lists. Might not be a meaningful organization to authors. Not all CMS systems provide either a single storage organization or any storage organization (topics might be maintained as a flat pool of topics). So definitely a design challenge. Keys, because they are context-dependent, do introduce a conceptual challenge for authors in that they must understand that there is this contextual aspect. In many situations authors may not even understand that there are alternative bindings for keys they use. I suspect that in more complex environments the only way to enable sensible authoring is to provide significant customization around the management of and access to keys within the authoring system. For example, I saw an automotive authoring system that was not DITA-based but used the equivalent of DITA 1.2 keys to enable links to logical topics that would vary based on the context established in the process of setting up an authoring session for a particular tree of topics. In this case you selected the model, model year, and subsystem, which was the equivalent of establishing the root map and ditaval parameters. The system was effectively constructing a compound map dynamically reflecting a particular sub tree of a much larger taxonomy. Once you had established that context, only then could you get write access to topics, where the underlying CMS provided the context-specific binding of keys to context-specific targets. That is the equivalent of setting a root map and specific sub maps that then establishe the set of effective key definitions for the authoring session. In a generic system I think the closest you can get is simply providing a way to select the root map. But in a more customized environment you might implement exactly this sort of locked-down authoring access approach. But that would have to be customization because it will always be in terms of a business-specific, information-set-specific subject or organizational taxonomy (e.g., cars and car parts vs software and subsystems). The best Oxygen can do is provide appropriate APIs and extension points to enable easy-as-possible implementation of this sort of authoring environment. Cheers, E. On 9/17/09 3:17 AM, "Radu Coravu" <radu_coravu@sync.ro> wrote:
Hi Eliot,
See some answers below:
ekimber wrote:
I notice that the insert keyref dialog only shows the keys descending from the map selected in the map manager. I'm not sure what else you can do, but I think I would like to have the option of setting a "keyref resolution context" for an editing session or a project, which would normally be the root map I'm working under.
In the case of the DITA 1.2 spec, there is a root map and then a number of subordinate maps, each with its own set of key definitions specific to that map (e.g., one for the L&T module, one for the Machine Industry module, etc.).
If I'm editing an L&T topic I may still need to refer to a base element's key, but to do that, I have to explicitly select the master map, not the L&T map (which is where I probably am if I've either opened that initially or navigated to it from the main map before navigating to the topic I want to edit). Not a deal killer, but it means you have to have the map open in order to select keys from it (of course, the editor will have to have processed the map in any case to make keys available, even if it doesn't show it in the map manager).
I could see having the "default key context" be a project-level setting.
We considered the adopted solution (using the current edited DITA Map as the context) as the easiest way to choose/resolve keyrefs without the need for additional configuration on the user part. Indeed in the case of maps which refer other maps it is not always a good solution and requires sometimes opening the master map just so that you can reference a key from its context. We'll try to come up with a way of being able to specify the master-map.
On the other hand, in a large content set you might have 10s of thousands of keys organized into many submaps, so just presenting a flat list of keys will not always be practical. Might be useful to have a tree view of the keys reflecting their organization into maps and submaps. But in that scenario, I can see that showing only the keys in a specific map helps because it implicitly narrows the selection.
The decision to have a flat representation of the list of keys was made because, if my interpretation of the DITA 1.2 is correct, keys can overwrite each other. If the layout has a tree structure maybe the user chooses a key from a sub-map believing it hrefs a location and in fact the key is overwritten in a parent map to point to another location. What do you think about this situation?
In my map specializations I now include a generic "keyset" topicref that simply serves to organize sets of keys within a map. Might be useful to have a key selector reflect any topicref hierarchy and navigation titles used in the map, on the assumption that such groupings must be significant.
Yes, indeed a problem with the flat selector. Maybe a tree table with a third "Navtitle" column would be better.
From an integration API standpoint I would want to have a "key definition provider" extension point so that a CMS could, for example, provide keys without the need to first open a map, so one could edit a topic from the CMS and still create key-based links to things the CMS knows about--I didn't look to see if such an API is already provided.
We have no such thing in the API, yet but it will be discussed.
Cheers,
E.
---- Eliot
Regards, Radu
---- Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc. email: ekimber@reallysi.com <mailto:ekimber@reallysi.com> office: 610.631.6770 | cell: 512.554.9368 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403 www.reallysi.com <http://www.reallysi.com> | http://blog.reallysi.com <http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>
George Cristian Bina wrote: Hi George, and all oXygen team,
We just uploaded oXygen 11 beta
Very good! The beta installs smoothly, and seems stable, as usual. The most interesting features are IMHO XProc support and XSLT documentation (the first two new features in your list :-p.) At first glance, the only feature I still miss is being able to open several projects at the same time. Just a few thoughts about the beta, just in case: - it seems it is not possible to use the same documentation system in XProc than in XSLT, that would be great though (but embedded in p:documentation elements of course); - there is no support for the XSLT document type within the p:xslt step. If oXygen completion is based on Relax NG, you can maybe use something like in this blog entry[1]. I think that's something that would make the XProc support very more convenient on a daily basis; - a few completion opportunities are not taken into account in XProc, for instance the port names on standard (or even user- defined) steps, as well as option names, or for step and port names on p:pipe; - maybe xmlns:c should be added on a new pipeline document, along with xmlns:p; - within XProc scenarii, there is nothing regarding input ports, and output ports are not taken from the selected pipeline (as opposed to the params in an XSLT scenario, that are listed from the selected stylesheet.) Anyway, those are just thoughts, and this is very nice to see XProc support in oXygen already! And there is even ${env(...)} substitution :-) [1]http://fgeorges.blogspot.com/2008/11/xproc-with-xslt-completion-in-oxygen.ht... Congrats! -- Florent Georges http://www.fgeorges.org/
Hi Florent, Thank you for your feedback! Please find my comments below. Florent Georges wrote:
George Cristian Bina wrote:
Hi George, and all oXygen team,
We just uploaded oXygen 11 beta
Very good! The beta installs smoothly, and seems stable, as usual. The most interesting features are IMHO XProc support and XSLT documentation (the first two new features in your list :-p.) At first glance, the only feature I still miss is being able to open several projects at the same time. Just a few thoughts about the beta, just in case:
- it seems it is not possible to use the same documentation system in XProc than in XSLT, that would be great though (but embedded in p:documentation elements of course);
The XSLT documentation is built for XSLT (as the XSD documentation is built for XML Schema) and analyzes the stylesheet determining the components, their documentation and where each component is used. That cannot be directly translated to XProc, and that is the main part of the documentation support.
- there is no support for the XSLT document type within the p:xslt step. If oXygen completion is based on Relax NG, you can maybe use something like in this blog entry[1]. I think that's something that would make the XProc support very more convenient on a daily basis;
I will look into this. The approach I am considering is to use the oXygen content completion for XSLT as that has the schemas annotated providing documentation for the XSLT instructions and attributes and may offer also some XPath completion support.
- a few completion opportunities are not taken into account in XProc, for instance the port names on standard (or even user- defined) steps, as well as option names, or for step and port names on p:pipe;
This is one area of improvement, yes. We have some specific handlers for XML Schema, XSLT, etc. that look into the document or offer some built in knowledge to enhance what we can determine automatically from a schema.
- maybe xmlns:c should be added on a new pipeline document, along with xmlns:p;
Ok, we will add a declaration in the default XProc template for the http://www.w3.org/ns/xproc-step namespace.
- within XProc scenarii, there is nothing regarding input ports, and output ports are not taken from the selected pipeline (as opposed to the params in an XSLT scenario, that are listed from the selected stylesheet.)
We will look into allowing to specify the input ports bindings in the scenarios. For the output we implemented the detection of output ports so it is a bug that it does not work.
Anyway, those are just thoughts, and this is very nice to see XProc support in oXygen already! And there is even ${env(...)} substitution :-)
[1]http://fgeorges.blogspot.com/2008/11/xproc-with-xslt-completion-in-oxygen.ht...
Congrats!
Thanks again for your feedback! Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com
Wanted to mention how much I like the new ability to navigate down through included maps in the Map Manager--very handy for using a map for navigation. Cheers, Eliot ---- Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc. email: ekimber@reallysi.com <mailto:ekimber@reallysi.com> office: 610.631.6770 | cell: 512.554.9368 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403 www.reallysi.com <http://www.reallysi.com> | http://blog.reallysi.com <http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>
Hi, We made available also an Eclipse plugin build of oXygen 11 beta Update site URL http://www.oxygenxml.com/update/beta11/Eclipse/site.xml Plugin zip http://www.oxygenxml.com/update/beta11/Eclipse3.4/com.oxygenxml.editor_11.0.... Please see the enclosed message below for additional details about oXygen 11 beta. Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com George Cristian Bina wrote:
Hi,
We just uploaded oXygen 11 beta, scroll down for the installation kits [1] and for a license key for tests [2]. I hope you will enjoy getting early access to the new version 11 features :). We expect to release version 11 in the first part of October.
Here it is a list with the most important changes:
XProc support ============= The XProc support includes editing, validation and execution through XProc scenarios. oXygen bundles Calabash as built in engine but additional custom XProc processors can also be configured. The Author mode presents a nice visual rendering of the XProc scripts.
XSLT documentation ================== oXygen generates documentation for XSLT stylesheets in XHTML format by inspecting the stylesheets and determining what components they contain and where they are used. User supplied description can be specified either in the form of XML comments or in a simple language for which oXygen provides easy editing support though special actions for inserting documentation and through content completion. User defined documentation languages can also be used but the rendering stylesheets need to be updated to handle their conversion to XHTML.
XQuery Debugger for the Berkeley DB XML database ================================================ The debugging interface of Berkeley DB 2.5 database was integrated with the XQuery Debugger of oXygen.
EMC Documentum integration ========================== oXygen XML Editor integration with Documentum is built on top of DFS 6.5 and includes: * Repository browsing * Check-out and check-in * Transparent resource access (open, edit, save) * Import/export * Resource management (create, delete, copy, move) * etc. A video demonstration showing that in action is available at http://www.oxygenxml.com/update/Documentum/oXygenDocumentum.html More details for setting up the connection to Documentum can be read here https://community.emc.com/thread/4519
More flexible transformation and validation scenarios ===================================================== There is no more a dependence btween the currently edited file and the scenarios available for transformation or validation, thus users can apply any transformation or validation scenario on any file. More, the project view allows to associate scenarios on a folder or on the selected files.
Updated Saxon to version 9.2 ============================ Saxon 9 SA was updated to the latest version Saxon 9.2 Enterprise Edition. oXygen supports also Saxon 9.2 Professional Edition and Home Edition.
Update oNVDL to jing-trang ========================== The NVDL implementation from oNVDL was moved to jing-trang and was updated to use the latest jing-tarang version 20090818.
Improved Author editing interface for non technical users ========================================================= The Author mode has new location tooltips and current element highlights that help the user to identify the position in the edited document. By default it turns on a more constrained editing mode that avoids for instance inserting text in the elements that do not allow text nodes or inserting elements not allowed by the schema.
Render and visually edit MathML in the Author mode ================================================== MathML notations are rendered and can be edited in Author mode with a default editor or with an optional and more powerful editor based on the MathFlow component from Design Science.
Render MathML in the output of DocBook transformations ====================================================== MathML notations included in a DocBook documents are rendered as graphic notations in the PDF and XHTML outputs of the DocBook transformations.
Integrated DITA OT 1.5 ====================== oXygen comes with version 1.5 (M19) of DITA OT which supports the DITA 1.2 specification.
DITA 1.2 support ================ Some of the new DITA 1.2 features are supported. These include insertion and visualization in the Author mode of conref ranges and conkeyrefs, insertion and navigation for keyrefs in the context of the current DITA map.
Spell checking on a set of files ================================ Spell checking can be applied with only one action on all the files in a folder from the Project view or on all the files referred by a DITA map from the DITA Maps Manager view.
Automatic/Easy setup for AntennaHouse Formatter =============================================== An installation of the AntennaHouse FOP v4 or v5 can be automatically detected or easily configured for performing FO to PDF transformations and for DITA map transformations executed with DITA OT.
Support for WMF images in the Author mode ========================================= WMF images can be rendered now in the Author mode.
Allow more than one toolbar with custom actions in Author mode ============================================================== You can create up to 4 toolbars containing custom actions that will be available in the Author mode.
Updated TEI schemas to version 1.4.1 ==================================== The latest version of TEI schemas were added.
XPath content completion for Schematron ======================================= The content completion offers XPath 1.0 and XPath 2.0 functions and axes in attributes like report/@test, value-of/@select, etc when editing a Schematron schema.
Support attributes in the XPath filter for Find/Replace ======================================================= The XPath filter of the Find/Replace dialog works also for an XPath expression that selects only attributes, thus it is possible to find/replace only in attribute values.
Extended large documents editing support ======================================== Larger XML documents can be opened for editing, for example a 200MB document can be opened in oXygen using a 512 MB or more. oXygen will detect large documents and will automatically turn off or change the implementation for some editor functions to reduce the memory usage.
Extended large documents viewing support (up to 10 GB) ====================================================== The large fie viewer can open files up to 10 GB in read only mode.
WebDAV sources available in the Database Explorer view ====================================================== The files and folders available in a WebDAV source can be browsed and opened using the Database Explorer view.
Digital signature without key info ================================== An XML document can be signed without including the key info in the signed document and the signature of a signed XML document that does not include key info can be verified.
Resolve imported XML Schema location based on namespace ======================================================= The location of an XML Schema imported in other schema can be resolved with an XML catalog based only on the schema namespace when the schema location is not specified.
[1] oXygen XML editor 11 beta installation kits: ================================================ Windows http://www.oxygenxml.com/update/beta11/Windows/VM/oxygen.exe
MacOSX http://www.oxygenxml.com/update/beta11/MacOSX/oxygen.tar.gz
Linux http://www.oxygenxml.com/update/beta11/Linux/VM/oxygen.sh Linux 64 http://www.oxygenxml.com/update/beta11/Linux64/VM/oxygen.sh
All platforms http://www.oxygenxml.com/update/beta11/All/oxygen.tar.gz
Test license key ================
--- start license key ---
Registration_Name=beta tests
Company=
Category=Enterprise
Component=XML-Editor, XSLT-Debugger, Saxon-SA
Version=11
Number_of_Licenses=1
Date=09-15-2009
Trial=31
SGN=MCwCFAnAP2PY5IsEQ5Hdxfd8QNj78MszAhQtljiO5WRwo71r6e8f8Ex7NrS+BQ\=\=
--- end license key ---
Best Regards, George
participants (4)
-
ekimber -
Florent Georges -
George Cristian Bina -
Radu Coravu