General XMetaL Discussion

  • eschulke

    RLX File location

    Participants 9
    Replies 10
    Last Activity 7 years, 11 months ago

    I'm perplexed about an issue where I think XMetaL is using a RLX file that it automatically created that is incorrect but I don't know where it is.

    We have the DTD in the Rules folder within XMetaL but the RLX is not in that location

    The DTD is not in the location with the XML

    So where else can the RLX exist? Β And how do I tell XMetaL where to put the RLX?

    I tried updating the extid.map file but that didn't do anything

    I also tried to build the RLX using Developer and put it in the Rules folder but that didn't help either

    Thanks

    Reply

    Derek Read

    Reply to: RLX File location

    If an RLX is present in the same folder as the DTD (or where the DTD should be) it will be loaded in preference to the DTD, unless the DTD is newer and in that folder. If the DTD is present and that folder is not writable then the RLX is generated in the per-user folder on your system. I cannot provide an exact path because I don't know which version you are running, but this should help you find it:

    %appdata%SoftQuadXMetaLgen

    So, for example, if you are running 9.0 and the DTD you are referencing is in C:somefoldermydtd.dtd then the path would be:

    %appdata%SoftQuadXMetaL9.0genCsomefoldermydtd.rlx

    If (at any point) you did not provide a CSS or CTM file then you will also find auto-generated versions there.

    Generally, if the DTD is altered the RLX should be updated to reflect those changes. However, when a DTD includes multiple files that process can fail with some versions, particularly if the changes are not in the main DTD file.

    Reply

    eschulke

    Reply to: RLX File location

    Thanks Derek – exactly what I needed to know – that solved my problem – Ed

    Reply

    barbwire

    Reply to: RLX File location

    I have a question about RLX files: why an earth they even exists? πŸ™‚ I mean, I know, that they are related to DTD, but when there is a DTD change, it could be that RLX file is not updated and therefore some times users ask questions, that is the DTD update already done, because “I'm not seeing the modifications in the element list whatever”. The fix for this kind of situations is easy: remove the RLX-file and then it is generated to the correct one.

    However, I would like to see change in XMetal, that RLX-file creation is an optional feature.

    Reply

    Derek Read

    Reply to: RLX File location

    The RLX, RLD and RLS files are a mechanism left over from the 1980s and 1990s when computers were slow (at that time the software was SGML only so there was only RLS). These files are essentially a pre-compiled version of the DTD, XSD, or SGML DTD.

    Ideally they should be generated and managed without anyone needing to worry about them, if you are distributing a DTD, and in the vast majority of cases they are. All of this should be invisible to the end user, but there is one case where these files will not be updated. Presumably that is the one you have found in your environment. Hopefully we'll address that. Whether the best solution is to address this issue or to rewrite the system so that the DTD is compiled every time it is loaded (not written to disk) I can't say.

    We also have developers that don't distribute their DTD, and just provide their users with the RLX file. There are various reasons why they would want to do that, but essentially it means that whoever receives the file cannot modify it.

    Reply

    barbwire

    Reply to: RLX File location

    Thanks for the answer. One more question:

    When Xmetal opens file for editing, does it use RLX-file for anything or is the topic validation based on the RLX-file, because it seems to be so?

    And now I got the speed… My all-time-favourite question: why an earth Xmetal does not respect the PUBLIC id if it says where file is found? (example: ) In my knowledge, other editors (at least most of them) respect the PUBLIC id and read the DTD for example same directory where the file is, but XMetal reads the file from it's own directory. Or does this happen because in this case XMetal can find “-//OASIS//DTD DITA Concept//EN” and therefore it does not use the “concept.dtd” what is mentioned on the DOCTYPE?

    Reply

    Derek Read

    Reply to: RLX File location

    The RLX file is a compiled version of the DTD, similar to the model that it creates in memory when it reads in a DTD file. Originally when computers were slower this was important since it could take a long time to create the model. The software still does this because it has always done so and was designed this way.

    As for reading in PUBLIC id values and SYSTEM id values, the software can be configured to load DTDs from anywhere you like but for DITA you do not want it to do that because if you do XMetaL Author will not load the DITA DTDs we include together with the customization (the rest of the functionality for editing DITA) that we have designed.

    When XMetaL Author Enterprise sees a DOCTYPE like the one you have in your message it does read in the SYSTEM id portion. In your case this is “concept.dtd”. The path is relative in this case, so it does look in the same folder as the XML file for the DTD — under normal circumstances. This is actually not something you want to have happen for DITA though, because the rest of the customization that drives all of the special DITA authoring functionality will not be loaded and the benefits of purchasing XMetaL Author Enterprise for its DITA authoring capability will be wasted. You will be editing your DITA XML files with the most rudimentary “edit as XML” functionality the software provides. Under normal circumstances, if the file is found in that folder it is loaded, and if you have put customization files in that folder they are also loaded. However, if it is not found in the same folder then the PUBLIC id is read in and XMetaL Author looks through all the catalog files it has loaded for a matching PUBLIC id. If one is found then it loads the DTD from the associated SYSTEM id value.

    For DITA authoring – specifically DITA – this is overridden (via script) since you will always want the DITA authoring customization to be loaded. This also allows the software to be easily configured to work with DITA specializations.

    XMetaL Author can be thought of as having three levels of support for XML editing:

    1) You provide the DTD and the software provides basic editing support for that DTD. At the very basic level two files are still required: CSS (for display of the XML) and CTM (which includes some display settings and sets various editing behaviours as well). These settings will be auto-generated in this case and the guesses the software makes may provide some good results for working with elements and attributes but in some cases they may not be as good as if a human designed them. We don't recommend this as you might as well use a less capable editing tool and save your money because a lot of the functionality the software is capable of will not be available. For temporary, or one-off cases this is still useful however. This is not XMetaL Author's strength though, #2 is its real strength.

    2) You (or a partner or other 3rd party) provide the DTD and design a “customization”. This includes at minimum carefully designed CSS and CTM files, but it may also include additional forms or dialogs, changes to the user interface including toolbars and menus, and other UI changes specific to editing this particular document or to the application as a whole (implemented mostly via macros inside MCR files). The customization adds whatever functionality you need to make it easy for your authors to work with a specific DTD by hiding complex functionality. For example: instead of typing in the full path to reference an image or other file as an attribute value (which might be necessary for #1 above) the customization can display a “browse for file” dialog.

    3) We provide the entire authoring experience. Currently this is limited to DITA authoring (though some people take the DocBook and other samples we include and use those as they are or build on them to create their own customization). For DITA everything works out of the box and clients do not need to provide the DITA DTDs or the customization files or the integration with the DITA Open Toolkit. Everything just works.

    Reply

    barbwire

    Reply to: RLX File location

    Once again, thanks for the long reply, but I afraid, that it raises more questions than answers. I'm actually very amazed currently.

    The RLX file is a compiled version of the DTD, similar to the model that it creates in memory when it reads in a DTD file. Originally when computers were slower this was important since it could take a long time to create the model. The software still does this because it has always done so and was designed this way.

    Thanks for this information.

    As for reading in PUBLIC id values and SYSTEM id values, the software can be configured to load DTDs from anywhere you like but for DITA you do not want it to do that because if you do XMetaL Author will not load the DITA DTDs we include together with the customization (the rest of the functionality for editing DITA) that we have designed.

    Tell me how to do this. I want to try to configure XMetal to load DTDs from anywhere where I like. Or do you basically mean something like modifying soc file, where PUBLIC id and path is told? If so, I have tried it already and it works actually. πŸ™‚

    When XMetaL Author Enterprise sees a DOCTYPE like the one you have in your message it does read in the SYSTEM id portion. In your case this is “concept.dtd”. The path is relative in this case, so it does look in the same folder as the XML file for the DTD — under normal circumstances. This is actually not something you want to have happen for DITA though, because the rest of the customization that drives all of the special DITA authoring functionality will not be loaded and the benefits of purchasing XMetaL Author Enterprise for its DITA authoring capability will be wasted.

    Okay, this is the part where I'm really amazed. Really I am, because in XMetal 6.0, 7.0, 8.0 and 9.0 XMetal does not read concept.dtd (or respect it), which is defined in the topic DOCTYPE. In 9.0 DTD is read from the ../DITA/XACs/1.2/concept/concept_ditabase.dtd and if not, I have to ask that what the f*ck because I remember that in webinar someone from your company admitted this also that DTD is read from the XMetal installation folder. πŸ™‚ It has always been, that we have to do certain things to get custom DTD's to work for end user. In 6.0 this is renaming certain folders from the XMetal installation and providing DITA-file, DTD and *.ctm, *.css etc. along the dita-file in the same folder. After those steps everything works well from DTD customizations to macros. No DITA functionality is missing from the Xmetal. In 8.0 this is more tricky, but we have succeeded with this also. The key has always been the same: remove certain folders from XMetal installation and make sure, that you have everything needed in the same folder than DITA-file.

    You will be editing your DITA XML files with the most rudimentary “edit as XML” functionality the software provides.

    I have never seen this if all necessary files are in the correct place.

    However, if it is not found in the same folder then the PUBLIC id is read in and XMetaL Author looks through all the catalog files it has loaded for a matching PUBLIC id. If one is found then it loads the DTD (dtd,ent,mod) from the associated SYSTEM id value.

    This seems to be true always. If files are found from the XMetal installation folder, it always tries to use those default DITA files. It never uses DTD, which is defined in the DOCTYPE unless the DTD is not default DITA. Me and my colleagues have seen this 100+n times so I'm pretty sure about this.
    —-
    But really, thanks for the answers. No disrespect for XMetal: I think that XMetal is good XML editor. You can PM me if you want. I really would like to know how to configure XMetal to use Xmetal read DTD from the different location than XMetal installation folder. I know how to do this, but if there is a easy way, I would like to know it. Using XMetal tools (inside editor) is not an option for me.

    Reply

    Derek Read

    Reply to: RLX File location

    Your conclusion is correct. Basically what I'm saying is that DITA is special, because the layer that makes all the special DITA authoring functionality work overrides the standard behaviours for look-up so that DITA files are treated as DITA (provided a recognized PUBLIC id is in the DOCTYPE) and so that you can easily select between the DITA DTD versions (1.1 or 1.2) by setting an option in Tools > DITA Options. All of these things force the software to use its own copy of the DTDs, which are copies obtain directly from the OASIS DITA Technical Committee. It also allows the software to be easily configured to use specialized DITA DTDs.

    I think you have two options (that are ultimately the same thing):

    1) We could attempt to disable all the DITA authoring functionality so that none of it is loaded and your copy of the DTDs are used instead.
    2) Use XMetaL Author Essential (which has no special DITA authoring capability like Enterprise does).

    The end result for both would be the editing capabilities I describe in #1 from my previous post. The latter of these two (above) would be the best solution if this is really what you need. I can't really recommend trying to disable the DITA authoring capabilities in Enterprise as it would involve either editing script files or deleting them, so it would be cleanest to just start with an installation that doesn't include the DITA authoring capabilities.

    I wonder why it is important to have XMetaL Author read alternate copies of the DITA DTDs? If they are unmodified copies (from OASIS) then there is no benefit (that I can see). If they are modified in some way then that is unsupported (at least with the DITA authoring functionality with Enterprise). What XMetaL Author Enterprise specifically supports is DITA specialization of the DTDs, and in this case you may place your specialized copy where you like provided you configure the software according to the instructions in Help.

    Reply

    barbwire

    Reply to: RLX File location

    I wonder why it is important to have XMetaL Author read alternate copies of the DITA DTDs? If they are unmodified copies (from OASIS) then there is no benefit (that I can see). If they are modified in some way then that is unsupported (at least with the DITA authoring functionality with Enterprise). What XMetaL Author Enterprise specifically supports is DITA specialization of the DTDs, and in this case you may place your specialized copy where you like provided you configure the software according to the instructions in Help.

    In short the reason for this is one Content Management System. When there is many Xmetal users it would be pain in the ass to write instructions, how they should create specialization after each modification to the DITA DTD's. Now CMS will provide DTD (OASIS DITA with customizations), macros, ctm etc. files to the users, so they don't have to do nothing. All XMetal installation provided DTD's are disabled. Users just use the XMetal without doing any changes by themselves. That is the main reason for this.

    Reply

    Derek Read

    Reply to: RLX File location

    Each CMS integration has different requirements and how its integration with XMetaL Author Enterprise functions will vary. So, if a CMS is involved you will need to follow any specific instructions provided by that vendor, especially if their installer (that modifies the XMetaL installation) does not do everything required to automatically set these things up.

    Reply

  • You must be logged in to reply to this topic.

Lost Your Password?

Products
Downloads
Support