I am setting up a process for authors who are not well versed in XML to create content based on a schema (XSD) that i have created.
The insert tags function is valuable in reaching this goal, however the current implementation that exists in this editor doesnt readily show all the options available, only those that have been used so far in the current document.
I have noticed that a few prepared templates, such as DocBook, have the available elements listed even though they have not been used yet. Is there a way for me to set my schema up, like how DocBook is, with the editor and then my authors will be able to have all options at their disposal?
I attempted to replicate the situation, using the DOCTYPE declaration and adding an entry in the catalog file, however when i run the xml file in the browser, the declaration seems to be expecting a DTD instead of an XSD.
Was i on the right track? Can it be done and still have my xml files load as required?
Thanks
-Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Alex. I agree that this is a top priority for the editor. My problem so far has been that I haven't yet found a parser that examines an XML Schema and allows the application to construct a data model.
This is what's happening with DTDs, hence the availability of DTD-based insertion helpers.
I am also working to drop MSXML on Windows (Linux already uses Xerces-C) so I only need to implement this three times: for DTD (this is ready), XSD and RELAX NG.
-Gerald
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Next question. I have found an application that has been able to convert my XSD schema into a DTD, and i inderted the following into the catalog file
<public publicId="-//******//DTD" uri="file:///C:/Program%20Files/XML%20Copy%20Editor/dtd/helptest.dtd"/>
at the top of my xml file, i added:
<!DOCTYPE Helpfile PUBLIC "-//******//DTD" "../helptest.dtd">
the xml file has a relative path as thats how it would find the dtd when parsed. Constraints to the project i am working on means i have to avoid absolute paths when necessary. For editing purposes, this is not a problem.
Obviously the public ID field doesnt actually contain asterisks, but an actual name.
Anyway, when i try this, the xml file runs correctly, but the editor will still only show the tags that are used in the file so far. am i missing a step? or doing this completely wrong?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
im fairly sure i do. i'm at home at the moment for the weekend with a public holiday on monday. I'll give it another go on tuesday and see what happens. failing that, i'll send you the samples you asked for.
I may have to check the schema to see if theres anything special that needs to go in there, or if the conversion stuffed something up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have managed to rectify the problem. The converted DTD was assuming a namespace instead of the default. It is now working as it should.
So for anyone else wanting to add predictive insertion of elements based on a schema:
add the line to the top of your xml doc
<!DOCTYPE $root element$ PUBLIC "$some identifier$" "$path to DTD$">
and add the line to the catalog file XML copy editor
<public publicId="$some identifier$" uri="$path to local DTD$"/>
where
$root element$ is the root element of your document
$some identifier$ is a name to identify your project
$path to DTD$ is a path (absolute or relative) to the DTD document that is validated against when the xml file is run.
$path to local DTD$ is a path (absolute or relative) to the DTD document that is used by XML Copy Editor.
Hope this helps anyone else in the future.
Thanks for your help Gerald.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Alex, if you try 1.1.0.5 you will find that the editor now supports XML Schema-based autocompletion and validation-as-you-type. It's still quite new, though, so I'm expecting to hit snags and teething problems along the way.
Best,
Gerald
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am setting up a process for authors who are not well versed in XML to create content based on a schema (XSD) that i have created.
The insert tags function is valuable in reaching this goal, however the current implementation that exists in this editor doesnt readily show all the options available, only those that have been used so far in the current document.
I have noticed that a few prepared templates, such as DocBook, have the available elements listed even though they have not been used yet. Is there a way for me to set my schema up, like how DocBook is, with the editor and then my authors will be able to have all options at their disposal?
I attempted to replicate the situation, using the DOCTYPE declaration and adding an entry in the catalog file, however when i run the xml file in the browser, the declaration seems to be expecting a DTD instead of an XSD.
Was i on the right track? Can it be done and still have my xml files load as required?
Thanks
-Alex
Thanks Alex. I agree that this is a top priority for the editor. My problem so far has been that I haven't yet found a parser that examines an XML Schema and allows the application to construct a data model.
This is what's happening with DTDs, hence the availability of DTD-based insertion helpers.
I am also working to drop MSXML on Windows (Linux already uses Xerces-C) so I only need to implement this three times: for DTD (this is ready), XSD and RELAX NG.
-Gerald
I see. But thats ok.
Next question. I have found an application that has been able to convert my XSD schema into a DTD, and i inderted the following into the catalog file
<public publicId="-//******//DTD" uri="file:///C:/Program%20Files/XML%20Copy%20Editor/dtd/helptest.dtd"/>
at the top of my xml file, i added:
<!DOCTYPE Helpfile PUBLIC "-//******//DTD" "../helptest.dtd">
the xml file has a relative path as thats how it would find the dtd when parsed. Constraints to the project i am working on means i have to avoid absolute paths when necessary. For editing purposes, this is not a problem.
Obviously the public ID field doesnt actually contain asterisks, but an actual name.
Anyway, when i try this, the xml file runs correctly, but the editor will still only show the tags that are used in the file so far. am i missing a step? or doing this completely wrong?
Thanks Alex. This is how I would approach this, too. If poss, do feel free to send me DTD and an instance doc and I can try this for myself.
Have you enabled validation-as-you-type under Tools>Options?
-Gerald
im fairly sure i do. i'm at home at the moment for the weekend with a public holiday on monday. I'll give it another go on tuesday and see what happens. failing that, i'll send you the samples you asked for.
I may have to check the schema to see if theres anything special that needs to go in there, or if the conversion stuffed something up.
I have managed to rectify the problem. The converted DTD was assuming a namespace instead of the default. It is now working as it should.
So for anyone else wanting to add predictive insertion of elements based on a schema:
add the line to the top of your xml doc
<!DOCTYPE $root element$ PUBLIC "$some identifier$" "$path to DTD$">
and add the line to the catalog file XML copy editor
<public publicId="$some identifier$" uri="$path to local DTD$"/>
where
$root element$ is the root element of your document
$some identifier$ is a name to identify your project
$path to DTD$ is a path (absolute or relative) to the DTD document that is validated against when the xml file is run.
$path to local DTD$ is a path (absolute or relative) to the DTD document that is used by XML Copy Editor.
Hope this helps anyone else in the future.
Thanks for your help Gerald.
Alex, if you try 1.1.0.5 you will find that the editor now supports XML Schema-based autocompletion and validation-as-you-type. It's still quite new, though, so I'm expecting to hit snags and teething problems along the way.
Best,
Gerald