Pages: « 1 2 3 4 5 6 7 8 9 10 »
 71 
 on: May 03, 2018, 01:23:11 PM 
Started by Marvin - Last post by Derek Read
I'll see if we can have someone look at that Schematron. Most likely it is simply incompatible with the Schematron engine we are using or the XSLT2 parser it runs on. Adjusting the file may be possible.

We should clarify what you mean by "validation" before answering your next question. Schematron is a language that allows you to make assertions about the presence or absence of specific patterns (whether nodes are present or not) in XML. This is different from the standard XML validation rules.

XMetaL Author is a "validating XML parser" and implements the standard validation rules according to the W3C's XML Recommendation. This feature is "live" at all times.

The best way to validate any XML document in XMetaL Author is to simply open the XML file. As long as it references a DTD or W3C Schema (aka: schema) the XML file will be validated immediately after the schema has been loaded. The same is true when you save -- validation is performed before the file is written out. You can also force validation to run at any time by selecting Validate from the Tools menu.

While editing an XML file another (proprietary) feature related to validation is engaged that we call "Rules Checking". This feature attempts to keep the document valid by not letting you put it into an invalid state when using the Element List, Attribute Inspector, via paste, etc. What this means is that if you start editing a valid document XMetaL will keep that document valid no matter what changes you make to it until you save.*

You can read more about the Validation and Rules Checking features in the help topic "Validation and rules checking".


* Note that this is not entirely true (though it is 99% of the time). XMetaL Author allows you to put a document into an invalid state in order to let you get to another valid state. One example is when an element must contain one (and only one) of multiple child elements and it already contains one of them. If you wish to insert a different child element XMetaL Author allows you to remove the existing child (putting the document into an invalid state) so you can insert one of the other allowed children. The majority of the cases will be similar, with XMetaL Author allowing you to delete things from a document putting it into a state where a required node might be missing. This is where validation comes in and that is why it is performed at file open and at file save.

 72 
 on: May 03, 2018, 07:38:58 AM 
Started by Marvin - Last post by Marvin
I would like to programmatically validate CALS tables in XMetaL Author 13.

I have found the following schematron:
https://github.com/nigelwhitaker/cals-table-schematron
https://github.com/nigelwhitaker/cals-table-schematron/blob/master/source/cals.sch

But when I try to run the validation using Tools->Validate using Schematron, I receive the following error message:

Quote
SEVERE: Exception com.google.gwt.core.client.JavaScriptException in invokeTransform: (TypeError) description: Object doesn't support property or method 'hasAttribute' number: -2146827850: Object doesn't support property or method 'hasAttribute'

Unexpected exception occured = Unable to get property 'xml' of undefined or null reference

Is this a problem with my XMetaL Author installation, or with that specific script?
Also, how can I call that validation programmatically?

Alternatively, is there a better way to validate CALS tables?

(Finally a quick bug report:
When you open Tools->Validate using Schematron and then choose "Select new Schematron file..." and click "Cancel" in the file open dialog, you can no longer open the file dialog, unless you either restart XMetaL or choose an existing Schematron file from the dropdown menu (i.e. if there is none you have to restart XMetaL Author). This is because the file dialog seems to be bound to an "selected item changed" event, but you cannot select the "Choose Schematron for validation" option, which is the only other option when there are now recent Schematron files in the list.)

 73 
 on: May 02, 2018, 03:58:49 PM 
Started by Marvin - Last post by Marvin
I'm sorry, my question was poorly worded.

We'd like the setting to be applied for many clients at the same time (at least when XMetaL Author is installed).
We already package macros and other customizations with the application, so it'd be great if we could just put this in some configuration file/macro/registry setting and then deploy that with the other files.

Sorry about the misunderstanding.

 74 
 on: May 02, 2018, 01:25:38 PM 
Started by Marvin - Last post by Derek Read
Look in the help under "Checking your spelling" then "Language settings".
That topic shows how to set the default spell checking language. In your case you will need to select "English-UK".

 75 
 on: May 02, 2018, 07:20:38 AM 
Started by Marvin - Last post by Marvin
All (or at least almost all) of our documents are in English and need to conform to Oxford (UK) English spelling.

As far as I know, we don't have any xml:lang tags in our documents.

Is there a way to set the default spellchecking language to UK English?

I found this thread, but I'm not sure if it's what I need.

What I want, is basically two things:

1. If no language is selected/detected, always fall back to "UK English".
2. If English is detected, always use the UK spelling (not US).

It would probably even be good enough to "hardwire" UK English spellchecking into the installation if that's easier.

Is there a setting we can adjust? Or would we have to use a macro?

Thank you.

 76 
 on: May 01, 2018, 03:17:18 PM 
Started by Marvin - Last post by Marvin
Thank you.

I could solve the problem, by replacing rng.pasteString with rng.InsertElement.

 77 
 on: May 01, 2018, 03:00:09 PM 
Started by Marvin - Last post by Marvin
Thanks!

 78 
 on: May 01, 2018, 02:59:00 PM 
Started by Marvin - Last post by Derek Read
If you aren't using XMetaL Developer you can still use Ctrl+Alt+R to reload macros.

This only helps for macros in events that can still run (ie: some events only fire at startup).

 79 
 on: May 01, 2018, 01:31:39 PM 
Started by Derek Read - Last post by Derek Read
This topic has been moved to DITA and XMetaL Discussion.

http://forums.xmetal.com/index.php?topic=3981.0

 80 
 on: April 30, 2018, 07:10:57 PM 
Started by Marvin - Last post by Derek Read
If this was for any DTD or W3C Schema other than DITA then it would make sense to try to figure this out. In that case you have full control over everything that is happening because the scripts you have created (your MCR files) are the only ones you need to worry about having conflicts with.

However, making modifications to the DITA authoring functionality is mostly not supported. CSS changes are supported, as are some configuration changes for CTM settings. However, because the entire DITA authoring system is implemented as an XMetaL customization that is running its own scripts, the only supported method for extending that functionality is by making modifications to a limited number of pre-defined scripting extension points. These are primarily meant to be used to add or change functionality for specialized DITA DTDs, but can also be used to alter some behaviours for the standard DITA DTDs.

They are limited to the following:

None of these will help you. I list them here because it may help to understand what is supported.



Specialization Extender:

  • OnSpecializeCommandBars - for adding or modifying toolbars and menus
  • OnSpecializeContextMenu - for adding or modifying context menu items (right click menu)
  • makeUniqueId - for changing how ID values are constructed (the format) for the DITA auto-id feature, by defaultthe Windows GUID generator is used
  • doProperties - provide a way to stop the context menu item for the DITA "Properties" dialog from being listed in the context of specific element(s)
  • OnGetDisplayNameForDomain - provides control over the items listed for "Domains" in the DITA options dialog

A .js file needs to be placed in the XACs folder for the particular DITA DTD you wish to extend this functionality for. There is a specific naming convention for that filename and there is a specific naming convention for each of the prototype functions (that allow for code extension) that need to be defined inside that file.

A demo file is included here:
C:\Program Files\XMetaL <version>\Author\DITA\XACs\<DITA DTD Version>\ditabase\ditabase_ditabase.off.js

To enable this functionality the file must be renamed to match the DTD filename in the same XACs subfolder for the particular DITA DTD you want to extend. So, for example, enable the demo file by renaming it ditabase_ditabase.js
Documentation for the file itself is included in inline comments inside the .js file listed above.

You may want to step through the DITA authoring code in a debug session to see what it does for any of the items you want to extend in order to understand how the existing code works. Without knowing that it is easy to break existing functionality. Two exceptions are possibly makeUniqueId and doProperties, which are quite simple and easily demonstrated by the provided demo code.



If you need to make modifications to a document programmatically, that might be done in a way that does not necessarily conflict with the DITA authoring functionality, but it would be difficult to support this. The APIs you are using in your sample code are ones that mimic behaviours that an author (end user) can do themselves, and so it might be possible to create a macro that does not get in the way of the DITA authoring functionality (which includes automatically setting DITA id attributes). To answer this for certain it would be best to provide a full (in your case not really working) sample to XMetaL Support to see if there is something that can be done. Again, this is unsupported so there are no guarantees, but it might be possible. XML file + MCR that includes whatever code you have so far and as much of a description as possible.

Keep in mind that "supported" also means something you create today will continue to function with all future versions. That is always true (short of introduced bugs that are later fixed) for all XMetaL APIs. However, it isn't true for the DITA functionality because of the potential for conflict, that the functionality might change in the future, and that it isn't documented to have been written to function in any specific way (unlike the XMetaL APIs). So, something created today that changes how the DITA authoring functions might work in a specific version but isn't guaranteed to work in the future (the only ones we plan to continue to support are those extension points listed above).

Pages: « 1 2 3 4 5 6 7 8 9 10 »