General XMetaL Discussion
Fendor May 13, 2009 at 3:20 pm
Loading a documentMay 13, 2009 at 3:20 pmParticipants 9Replies 10Last Activity 13 years, 1 month ago
Is there any chance to load an XML document by script without facing the dialog which requests DTD and other files?Derek Read May 14, 2009 at 6:05 pm
Reply to: Loading a documentMay 14, 2009 at 6:05 pm
With a properly configured customization (DTD/XSD + CSS + CTM + MCR, etc) your end users should never see the prompt to browse for a DTD or Schema. Please see the help topic (and those it links to): “What to do if the DTD, Schema, or rules file cannot be found”.
There is also a lot of information about configuring XMetaL Author to use a specific DTD/XSD (and customization files) in the XMetaL Developer Customization Guide, along with information about building and deploying an XAC file (if that is an option or preference).dcramer May 14, 2009 at 7:21 pm
Reply to: Loading a documentMay 14, 2009 at 7:21 pm
“With a properly configured customization (DTD/XSD + CSS + CTM + MCR, etc) your end users should never see the prompt to browse for a DTD or Schema.”
Ok, you're talking about one of my favorite subjects now. I can think of some situations where they'll get this dialog:
Let's say I have a file that includes other files as entities (a.xml includes in its doctype and has &b.xml; somewhere). Now:
1. Have a.xml open and have clicked on the entity to open b.xml from a.xml. I'm editing both with all my dtd-specific customizations etc. Now I close XMetaL. Next time I open XMetaL, it opens its workspace and tries to open both a.xml and b.xml, but this time it can't figure out that b.xml is part of a.xml and should use a.xml's doctype. So you're prompted to find the dtd and do not even have the option of telling it you want to use a.xml's doctype. Your only choice is to finish opening b.xml (e.g. in plain text), close the b.xml, and reopen it from a.xml.
2. Have a.xml open and have clicked on the entity to open b.xml from a.xml as above. Now you edit b.xml with an external editor (say you want to do a search and replace across attribute values or maybe you ran a sed script across all the files to globally change something). Now you return to b.xml in XMetaL. On_Document_Activate from macros.mcr fires and you see the “The disk version of this document has changed from the version in memory. Do you want to re-open the document?” You click “Yes” and are faced with the same useless “Find the DTD” dialog.
The situation in #2 will also happen if you have a “Reload Document” macro of your own that you want to run to reload images that have been changed by an application outside of xmetal.Fendor May 15, 2009 at 7:11 am
Reply to: Loading a documentMay 15, 2009 at 7:11 am
Unfortunatelly the users of my script shall not always be equipped with valid DTD files. But still they will need to be able to get the text content from numerous XML documents, even not well formed. They only need text without any formatting or structurization.
Can XMetal do that, e.g. read silently a document and return its text? Or we'll have to create a separate XML parser for that?Derek Read May 15, 2009 at 8:19 pm
Reply to: Loading a documentMay 15, 2009 at 8:19 pm
Yes. When a DTD cannot be located you are given several choices. You might choose the second or third option if you do not have a DTD. In this you will obviously no validation will be possible (and so one major reason for using the product will be lost in that case).Derek Read May 15, 2009 at 8:35 pm
Reply to: Loading a documentMay 15, 2009 at 8:35 pm
XMetaL Author supports a processing instruction that allows you to specify the path to a supporting DTD for editing well-formed documents. It puts XMetaL Author into “well formed” editing mode immediately. This is the equivalent of selecting the second option when you are prompted to browse for a DTD, checking the box “Choose auxiliary Rules/DTD/Schema”, and then browsing to the DTD.
If the DTD is placed inside the same folder as the XML document or inside the Rules folder you can use this:
If the DTD is located elsewhere you can use a full path:
Note that if you do not select a DTD (do not check the box) the PI is inserted and points to a newly created “DTD” with no content placed in the same folder as the XML document. As stated previously though, the vast majority of our clients actually use a DTD and have the customization files that go along with it so there XML renders nicely and the UI has been customized to help the users edit the document.
dcramer: you might experiment with this to see if this helps with your issue of editing external entities.Derek Read May 15, 2009 at 8:47 pm
Reply to: Loading a documentMay 15, 2009 at 8:47 pm
Alternatively, you can specify a DTD, Schema, or rules file to supply a set of elements and attributes for the document. If you choose such a DTD or rules file, XMetaL Author adds a processing instruction to your document that points to it. Any elements and attributes specified in the DTD are available to the document, but because the document is not officially based on the DTD, no rules checking or validation of the document occurs. All attributes are of type CDATA, that is, they can contain text without restriction.dcramer May 16, 2009 at 12:30 pm
Reply to: Loading a documentMay 16, 2009 at 12:30 pm
Here are what appear to me to be the limitations of that approach (let me know if there's a way around them):
1. When I open a partial document with one of those PIs, I don't get prompted for a DTD, but it doesn't load any of my customizations associated with the document either (no css, no ctm, no macro file).
2. The validate command is disabled after opening the document.
3. Even if it did open with my customization and with the validation command enabled, there would be the problem that the DTD doesn't include any entities declared in the DOCTYPE of the parent document (i.e. ]>)
The way other editors handle this is to allow you to include a comment or PI that points to the parent document. The editor sees this and opens the document fragment as if it includes the parent document's DOCTYPE statement.
ThanksFendor May 17, 2009 at 9:26 am
Reply to: Loading a documentMay 17, 2009 at 9:26 am
we are almost there. is there any chance to avoid this dialog and
somehow tell XMetal that we need to open the document without a DTD?
basically I need a script which opens 3 documents automatically without
any selection dialogs shown.Derek Read May 19, 2009 at 7:13 pm
Reply to: Loading a documentMay 19, 2009 at 7:13 pm
I can think of a few possibilities, however, the product was not designed to do what you want to do so we are pushing the boundaries here (with the possibility that what you want is just not possible).
1) Modify the XML documents so that they are opened automatically as well-formed (using the method previously noted on this post). You could do this using a batch process of some kind (string find and replace, XSLT, or other means) using various 3rd party tools.
2) Create an application-level event macro called On_Application_Before_Document_Open. The script in this macro would open the file (using something like the Windows File System Object, ADODB.Stream, MSXML or another XML parser) to insert the PI (same as solution #1 above) into the document so that XMetaL will treat it as well-formed and standalone. Then it would save the document and allow the document open event to complete (by not setting the Application.CancelOpenDocument property). If you wish to remove this PI (no real reason unless other software you have objects to it, which it should not) you will then need to override the Save and SaveAs features to take care of writing out the document yourself as there is not way short of a script switching to PlainText view to remove a PI outside the root element of a document using the standard XMetaL APIs.
3) Add your own “Open Well Formed Document” feature. It may or may not be possible to detect if the document contains a SYSTEM or PUBLIC ID (and therefore bypass the dialogs you want to bypass) without doing this at the application level, similar to #2. It might be possible to create a similar On_Application_Before_Document_Open script that places the entire XML document in a string variable, then cancels the original open using Application.CancelOpenDocument, and instead opens the document using Documents.OpenString() with the boolWFEdit parameter set to true.
As I think more about this I think the easier option would be #3, though there might be even more possibilities.
- You must be logged in to reply to this topic.