NLM.xml file is using oXygen's soextblx.dtd and erroring

[pschuller]

I am trying to apply a simple transformation to an xml file (which has a file extension of nlm.xml) When I hit the Apply Transformation Scenario button I get an error: A '(' character or an element type is required in the declaration of element type 'entry' The line of code causing that error is in soextblx.dtd which is in the oXygen ProgramFiles-etc directory. The line in soextblx.dtd is:
<!ELEMENT entry (%tbl.entry.mdl;)*>

The second line of the my xml file reads:
<!DOCTYPE article SYSTEM "journalpublishing-cals.dtd">
That dtd file is in the same directory as the xml file.

I saw a post that said to uncheck the Use Default Catalog checkbox in Options> Preferences> XML> XML Catalog - and I did that but I still get the same error.

Finally, I dont need oXygen to validate my incoming nlm.xml file. If I can turn off validation that may be the best thing. Can someone advise on that too?

[sorin_ristache]

Hello,

The line of code causing that error is in soextblx.dtd which is in the oXygen ProgramFiles-etc directory. The line in soextblx.dtd is:
<!ELEMENT entry (%tbl.entry.mdl;)*>

The second line of the my xml file reads:
<!DOCTYPE article SYSTEM "journalpublishing-cals.dtd">
That dtd file is in the same directory as the xml file.

The soextblx.dtd file is one of the DocBook 4 DTD files. It seems your DTD journalpublishing-cals.dtd tries to include it. We need the journalpublishing-cals.dtd file or a reduced sample DTD so that we can reproduce the problem. If it is not a large DTD you can post it here otherwise you can send it as a zip archive.

I saw a post that said to uncheck the Use Default Catalog checkbox in Options> Preferences> XML> XML Catalog - and I did that but I still get the same error.

If you do not indend to include one of the Docbook DTD files you should disable the Oxygen default catalog by unchecking that checkbox but make sure that you either reopen the XML file that contains the declaration

Code: Select all

<!DOCTYPE article SYSTEM "journalpublishing-cals.dtd">

or restart Oxygen after an XML catalog change that you apply in Preferences as you can read in the XML Catalog preferences panel.

Finally, I dont need oXygen to validate my incoming nlm.xml file. If I can turn off validation that may be the best thing. Can someone advise on that too?

The XSLT transformation does only a well-formedness check on the XML file and this cannot be avoided. I think the XML file that references your DTD (that includes soextblx.dtd) is not a well-formed XML file. In such a case it cannot be transformed with an XSLT stylesheet.


Regards,
Sorin

[pschuller]

Thanks for your reply. Closing Oxygen and re-opening (with the Use Default Catalog box un-checked) made the soextblx.dtd problem go away. Another issue came up that I have to work on. One more question for now ...

The dtd that the xml file calls (journalpublishing-cals.dtd, pasted below) ends up referencing about 130 files in 4 directories on the hard disk. The vendor is telling us they are using "NLM" and that that is an industry standard. Does this sound like an industry standard mark up? - impressions?

Here's the content of journalpublishing-cals.dtd. Thanks.

<!-- ============================================================= -->
<!-- MODULE: Journal Publishing DTD -->
<!-- VERSION: 2.3 -->
<!-- DATE: February 2007 -->
<!-- -->
<!-- ============================================================= -->

<!-- ============================================================= -->
<!-- PUBLIC DOCUMENT TYPE DEFINITION -->
<!-- TYPICAL INVOCATION -->
<!--
"-//NLM//DTD Journal Publishing DTD v2.3 20070202//EN"
Delivered as file "journalpublishing.dtd" -->
<!-- ============================================================= -->


<!-- ============================================================= -->
<!-- SYSTEM: Journal Publishing DTD of the -->
<!-- Archiving and Interchange DTD Suite -->
<!-- -->
<!-- PURPOSE: DTD for creation of new journal articles -->
<!-- -->
<!-- This subset of the Journal Archiving and -->
<!-- Interchange DTD is optimized for the authoring -->
<!-- (or initial XML tagging) of journal articles and -->
<!-- some non-article material such as product and -->
<!-- book reviews. It describes both the metadata for -->
<!-- a journal article and the full content of the -->
<!-- article. -->
<!-- This DTD was constructed using the modules in the -->
<!-- Archiving and Interchange DTD Suite. -->
<!-- -->
<!-- CONTAINS: 1) Declare and invoke the Publishing (Blue) DTD- -->
<!-- specific module of modules, that names any -->
<!-- modules created expressly for this DTD. -->
<!-- (%journalpubcustom-modules.ent;) -->
<!-- 2) Declare and invoke the DTD Suite module of -->
<!-- modules (%modules.ent;), the Archiving and -->
<!-- Interchange Suite module that names all the -->
<!-- Suite modules this DTD might invoke -->
<!-- 3) Invoke DTD-specific classes over-ride module -->
<!-- (%journalpub-classes.ent;) -->
<!-- 4) Invoke Suite default classes -->
<!-- (%default-classes.ent;) -->
<!-- 5) Invoke DTD-specific mixes over-ride module -->
<!-- (%journalpubcustom-mixes.ent;) -->
<!-- 6) Invoke Suite default mixes -->
<!-- (%default-mixes.ent;) -->
<!-- 7) Invoke DTD-specific content model over-ride -->
<!-- module (%journalpubcustom-models.ent;) -->
<!-- 8) Invoke the Common Element Module (from Suite) -->
<!-- 9) Invoke all the Class Modules (from Suite) as -->
<!-- well as any DTD-specific element modules -->
<!-- 10) Parameter Entities for attribute values used -->
<!-- in this module (DTD-specific definitions) -->
<!-- 11) Define document element (Article <article>) -->
<!-- 12) Define Front Matter <front> -->
<!-- 13) Define Body Matter <body> -->
<!-- 14) Define Back Matter <back> -->
<!-- -->
<!-- CREATED FOR: -->
<!-- Digital Archive of Journal Articles -->
<!-- National Center for Biotechnology Information -->
<!-- (NCBI) -->
<!-- National Library of Medicine (NLM) -->
<!-- -->
<!-- ORIGINAL CREATION DATE: -->
<!-- February 2003 -->
<!-- -->
<!-- CREATED BY: Jeff Beck (NCBI) -->
<!-- B. Tommie Usdin (Mulberry Technologies, Inc.) -->
<!-- -->
<!-- The Journal Publishing DTD is built from the -->
<!-- Archiving and Interchange DTD Suite. -->
<!-- -->
<!-- Suggestions for refinements and enhancements to -->
<!-- this DTD should be sent in email to: -->
<!-- publishing-dtd@ncbi.nlm.nih.gov -->
<!-- ============================================================= -->




<!-- ============================================================= -->
<!-- MODULES OF MODULES INVOKED -->
<!-- ============================================================= -->


<!-- MODULE TO NAME DTD-SPECIFIC MODULES -->
<!-- Names all DTD-specific external modules -->
<!ENTITY % journalpubcustom-modules-cals.ent
PUBLIC
"-//NLM//DTD Journal Publishing DTD-Specific Modules v2.3 20070202//EN"
"journalpubcustom-modules-cals.ent" >
%journalpubcustom-modules-cals.ent;


<!-- MODULE TO NAME THE MODULES -->
<!-- Declares all the external modules that are
part of the modular Journal Archiving and
Interchange DTD Suite library. Thus it does
NOT declare itself; the DTD-specific
module-of-modules; or the DTD-specific class,
mix, or model over-ride modules. Those are
declared in the DTD-specific module of modules.
Since this module declares but does not
invoke modules, this DTD invokes any modules
it uses by referencing the external
Parameter Entities defined in the Module of
Modules. To include a set of elements (such
as all the lists or the MathML elements) this
module defines the external Parameter Entity
for the module(s) that contains the MathML
declarations and the DTD references that
entity. -->
<!ENTITY % modules.ent PUBLIC
"-//NLM//DTD Archiving and Interchange DTD Suite Module of Modules v2.3 20070202//EN"
"modules.ent" >
%modules.ent;


<!-- ============================================================= -->
<!-- CUSTOMIZATION MODULES INVOKED -->
<!-- Note: These modules must be called after -->
<!-- all Module of Modules but before any other -->
<!-- modules. Unlike any other grouping, order -->
<!-- of these modules matters. -->
<!-- ============================================================= -->


<!-- DTD-SPECIFIC CLASS CUSTOMIZATIONS MODULE -->
<!-- Names the module that holds the DTD-specific
class definitions for the Journal Publishing
DTD that will over-ride classes in the Suite.
(Defined in %journalpubcustom-modules.ent;)-->
%journalpubcustom-classes-cals.ent;


<!-- DEFAULT ELEMENT CLASSES MODULE -->
<!-- Names the module that holds the standard
class definitions for the Journal Archiving
and Interchange DTD Suite. -->
%default-classes.ent;


<!-- DTD-SPECIFIC MIX CUSTOMIZATIONS MODULE -->
<!-- Set up the Parameter Entities and element
class definitions that will be used to
over-ride some element mixes in this DTD.
(Defined in %journalpubcustom-modules.ent;)-->
%journalpubcustom-mixes.ent;


<!-- DEFAULT MIX CUSTOMIZATIONS MODULE -->
<!-- Names the module that holds the standard
mix definitions for the Journal Archiving
and Interchange DTD Suite. -->
%default-mixes.ent;


<!-- DTD-SPECIFIC MODELS/ATTRIBUTES CUSTOMIZATIONS
MODULE -->
<!-- Names the module that holds the over-rides
of content models, attribute lists, elements
lists to be used in content models, and
attribute values. These are DTD-specific.
(Defined in %journalpubcustom-modules.ent;)-->
%journalpubcustom-models.ent;



<!-- ============================================================= -->
<!-- COMMON (SHARED) ELEMENTS MODULE INVOKED -->
<!-- ============================================================= -->


<!-- COMMON (SHARED) DECLARATIONS -->
<!-- Declarations for elements, attributes,
entities, and Notations that are shared by
more than one class module. Note: Must be
called before any of the class modules. -->

%common.ent;


<!-- ============================================================= -->
<!-- JOURNAL ARTICLE CLASS ELEMENTS (alpha) -->
<!-- ============================================================= -->


<!-- ARTICLE METADATA ELEMENTS -->
%articlemeta.ent;


<!-- BACK MATTER ELEMENTS -->
%backmatter.ent;


<!-- DISPLAY (GRAPHICAL) ELEMENTS -->
%display.ent;


<!-- FORMATTING ELEMENT CLASSES -->
<!-- Elements that change rendition/display. -->
%format.ent;


<!-- JOURNAL METADATA ELEMENTS -->
%journalmeta.ent;


<!-- LINK CLASS ELEMENTS -->
%link.ent;


<!-- LIST CLASS ELEMENTS -->
%list.ent;


<!-- MATH ELEMENTS -->
%math.ent;


<!-- NLM CITATION ELEMENT -->
%nlmcitation.ent;


<!-- PARAGRAPH-LEVEL ELEMENTS -->
%para.ent;


<!-- PHRASE-LEVEL ELEMENTS -->
%phrase.ent;


<!-- BIBLIOGRAPHIC REFERENCE (CITATION)
CLASS ELEMENTS -->
%references.ent;


<!-- SECTION ELEMENTS -->
%section.ent;


<!-- ============================================================= -->
<!-- THE REST OF THE EXTERNAL MODULES INVOKED -->
<!-- ============================================================= -->


<!-- MATHML SETUP MODULE -->
<!-- Invoke the MathML modules -->
%mathmlsetup.ent;



<!-- XHTML TABLE SETUP MODULE -->
<!-- Set up the necessary Parameter Entity values
and then invoke XHTML (HTML 4.0) table
module -->
%XHTMLtablesetup.ent;


<!-- OASIS TABLE SETUP MODULE -->
<!-- Set up the necessary Parameter Entity values
module -->
%oasis-tablesetup.ent;


<!-- SPECIAL CHARACTERS DECLARATIONS -->
<!-- Standard XML special character entities
used in this DTD -->
%xmlspecchars.ent;


<!-- CUSTOM SPECIAL CHARACTERS DECLARATIONS -->
<!-- Custom special character entities created
specifically for use in this DTD Suite -->
%chars.ent;


<!-- NOTATION DECLARATIONS MODULE -->
%notat.ent;


<!-- ============================================================= -->
<!-- PARAMETER ENTITIES FOR ATTRIBUTE VALUES -->
<!-- ============================================================= -->


<!-- ARTICLE TYPES -->
<!-- What kind of article is this? All articles
should have types assigned if possible.
-->
<!ENTITY % article-types
"abstract | addendum | announcement |
article-commentary | book-review |
books-received | brief-report | calendar |
case-report | collection | correction |
discussion | dissertation |
editorial | in-brief |
introduction | letter | meeting-report |
news | obituary | oration | other |
partial-retraction | product-review |
rapid-communication |
reply | reprint | research-article |
retraction | review-article | translation" >


<!-- ============================================================= -->
<!-- PARAMETER ENTITIES FOR ATTRIBUTE LISTS -->
<!-- ============================================================= -->


<!-- DTD VERSION -->
<!-- What version of this DTD was used to make
the document instance under consideration.
Note that this is a fixed value that should
change every time the DTD changes versions or
revisions. -->
<!ENTITY % dtd-version
"dtd-version
CDATA #FIXED '2.3'" >



<!-- ARTICLE ATTRIBUTES -->
<!-- Attributes for the top-level element
<article> -->
<!ENTITY % article-atts
"article-type
(%article-types;) #IMPLIED
%dtd-version;
xml:lang NMTOKEN 'EN'
%XLINK.xmlns.attrib;
%MATHML.xmlns.attrib;
%Schema.xmlns.attrib;" >


<!-- SUB-ARTICLE ATTRIBUTES -->
<!-- Attributes for the <sub-article> element -->
<!ENTITY % sub-article-atts
"article-type
(%article-types;) #IMPLIED
id ID #IMPLIED
xml:lang NMTOKEN 'EN'" >


<!-- RESPONSE ATTRIBUTES -->
<!-- Attributes for the <response> element -->
<!ENTITY % response-atts
"response-type
CDATA #IMPLIED
id ID #IMPLIED
xml:lang NMTOKEN 'EN'" >


<!-- ============================================================= -->
<!-- JOURNAL ARTICLE ELEMENTS -->
<!-- ============================================================= -->


<!-- ARTICLE MODEL (LIMITED) -->
<!-- Article-like model used for, for example,
a short sub-article such as a news brief that
is contained in side a journal article.
Only the metadata (<front> for full metadata
or <front-stub> for article metadata,
inheriting the rest from the parent article)
is required, although typical short articles
also have a body and may have references or
other back matter.
The <floats-wrap> container element is just
a wrapper to hold the floating objects
that occur anywhere in the article. Some
publishers like to collect all the floating
objects (figures, tables, text boxes,
graphics, etc.) together at the end rather
than interspersing them throughout the parts
of the article where they are referenced. -->
<!ENTITY % article-short-model
"((front | front-stub), body?, back?,
floats-wrap?)" >


<!-- ARTICLE MODEL WITH SUBARTICLE OR RESPONSE -->
<!-- Typical journal article model, which may
contain extended components, such as
sub-articles or responses, but which usually
contains neither.
The <floats-wrap> container element is just
a wrapper to hold the floating objects
that occur anywhere in the article. Some
publishers like to collect all the floating
objects (figures, tables, text boxes,
graphics, etc.) together at the end rather
than interspersing them throughout the parts
of the article where they are referenced. -->
<!ENTITY % article-full-model
"(front, body?, back?, floats-wrap?,
(sub-article* | response*) )" >


<!-- ARTICLE -->
<!-- The complete content of a journal article.
An article is potentially divided into
four (more typically three) parts: 1) the
Front Matter (article metadata or header),
the body of the article (main content), any
ancillary information such as a glossary or
appendix, and (the least common) a
response, that is a commentary on the
article itself. -->
<!ELEMENT article %article-full-model; >

<!ATTLIST article
%article-atts; >


<!-- ============================================================= -->
<!-- FRONT MATTER ELEMENTS -->
<!-- ============================================================= -->


<!-- FRONT MATTER MODEL -->
<!-- Model for the <front> matter (the header
metadata) of a journal article) -->
<!ENTITY % front-model "(journal-meta, article-meta,
(%front-back.class;)? )" >


<!-- FRONT MATTER -->
<!-- The metadata concerning an article, such as
the name and issue of the journal in which it
appears and the name and author(s) of the
article.
In some journal DTDs this is called the
header information, and it includes metadata
concerning the journal <journal-meta> and
metadata concerning the issue of the journal
and the individual article <article-meta>. -->
<!ELEMENT front %front-model; >


<!-- ============================================================= -->
<!-- BODY ELEMENTS -->
<!-- ============================================================= -->


<!-- BODY MODEL -->
<!-- Content model for the Body (main textual
content) of a journal article. -->
<!ENTITY % body-model "((%para-level;)*, (%sec-level;)*,
sig-block?)" >


<!-- BODY OF THE ARTICLE -->
<!-- The main textual portion of the article that
conveys the content. -->
<!ELEMENT body %body-model; >


<!-- ============================================================= -->
<!-- BACK MATTER ELEMENTS -->
<!-- ============================================================= -->


<!-- BACK MATTER MODEL -->
<!-- Content model for the Back Matter (ancillary
material such as appendices) of a journal
article. -->
<!ENTITY % back-model "(title*, (%doc-back-matter-mix;)* )" >


<!-- BACK MATTER -->
<!-- Ancillary or supporting material not included
as part of the main textual content of a
journal article, for example appendices and
acknowledgments. -->
<!ELEMENT back %back-model; >


<!-- ============================================================= -->
<!-- SUBARTICLE -->
<!-- ============================================================= -->


<!-- SUBARTICLE MODEL -->
<!-- Content model for the <sub-article> element
-->
<!ENTITY % sub-article-model
"((front | front-stub), body?, back?,
floats-wrap?, (sub-article* | response*) )"
>


<!-- SUBARTICLE -->
<!-- An article that is completely contained
inside another article. Both the article and
the sub-article have their own metadata. The
article has at very least journal and issue
information and start and end pages; it may
have a title, author, or other metadata.
The sub-article has its own, independent
metadata, such as authors, that it
may not share with the article that
encloses it.
Conversion Note: "Superarticles" that contain
other articles rarely contain much content of
their own, perhaps just a title and
introductory paragraph.
Authoring Note: This construction is NOT to
be used for an article and its response, or
for a series of responses, even if the
original article to which the responses are
replying is elsewhere. -->
<!ELEMENT sub-article %sub-article-model; >

<!ATTLIST sub-article
%sub-article-atts; >


<!-- FRONT MODEL STUB -->
<!-- Content model for the <front-stub> element,
a reduced metadata set for use in
sub-articles and responses, which will
inherit and metadata not defined in the stub
from their enclosing article. -->
<!ENTITY % front-stub-model
"(article-id*, title-group?,
(contrib-group | aff)*, author-notes?,
( (fpage, lpage?, page-range?) |
elocation-id)?,
history?, permissions?, abstract*)" >


<!-- STUB FRONT METADATA -->
<!-- Ancillary or supporting material not included
as part of the main textual content of a
journal article, for example appendices and
acknowledgments. -->
<!ELEMENT front-stub %front-stub-model; >


<!-- ============================================================= -->
<!-- RESPONSE ELEMENTS -->
<!-- ============================================================= -->


<!-- RESPONSE -->
<!-- Reply, response, or commentary concerning the
journal article. In the typical case, the
response is included in the same XML package
as the original article, and thus attached
at the end of the article proper.
Authoring Note: Frequently a reply or
response is an article in its own right, not
included as part of the original article.
Such an article could use the
<related-article> element in the article
metadata to record the metadata for the
original article.
Conversion Note: This construction can also
be used for the pathological case, rarely
seen, in which several responses to an
article are lumped together into a single
container which is not the original article,
merely a collection of responses. In one
example we examined, the first two responses
were to an original article which was else-
where and the third response was a response
to the first two responses. -->
<!ELEMENT response %article-short-model; >
<!-- response-type
What kind of response is this?
Note: This does NOT define the kind of
article on which the response is commenting,
it is metadata for the response itself.
Suggested values include:
addendum Adds additional information or
clarification to the parent
article
discussion Discussion related to a specific
issue described in the parent
article
reply Reply to the parent article.
This is the most commonly used
value.
xml:lang The language in which the value of the
element is expressed. Recommended best
practice is to use values as defined in
RFC 1766, typically 2-letter language
codes such as "FR" (French), "EN" (English),
and "DE" (German). These values are NOT
case sensitive, so "EN" = "en". The values
may include hyphenated differentiations such
as "EN-AU" (Australian English) and "EN-US"
(United States English).
Processing and Conversion Note: All other
xml:lang attributes within the article
inherit the value set on <article> unless
explicitly set themselves with their own
"xml:lang" attribute. -->
<!ATTLIST response
%response-atts; >


<!-- ================== End Journal Publishing DTD =============== -->

[sorin_ristache]

Hello,

Journal Publishing is a standard schema available on the NLM website.


Regards,
Sorin

[mseligy]

Hello
I am trying to transform XML docs from a slight variant of the NLM Journal publishing tag suite v3.0 to a slightly different doc with the same DTD. I keep getting the soextblx.dtd error reported in this post, and I have tried (several times) unchecking the default Oxygen catalog, closing Oxygen, then reopening my file. But the program is still looking for that soextblx.dtd.

I even tried specifying my own catalog in the XML catalog preferences area (we use other DTDs besides the NLM noted above), and this did not work either.

Also, I cannot see how our DTD is calling in the soextblx.dtd to begin with.

Any advice would be very much appreciated.

[ionela]

Hello,

I have tested NLM Journal publishing v3 with Oxygen v15, and it works fine if you add the NLM standard catalog, catalog-v3.xml, in oXygen preferences (Option > Preferences > XML / XML Catalog).

There is no need to disable the default Oxygen catalog. If you have a custom catalog, make sure you also refer the standard one (catalog-v3.xml) or add both to oXygen preferences ("XML Catalog").

If you want to prevent Oxygen from resolving the public ID "-//OASIS//DTD XML Exchange Table Model 19990315//EN" to soextblx.dtd, you can bypass/remove the DocBook 4 XML catalog. You can do this in Options > Preferences, Document Type Association, Edit "DocBook 4", Catalogs tab. If you don't work with or need DocBook 4, you can simply disable the DocBook 4 document type from the Document Type Association option page and the DocBook 4 XML catalog will also be disabled.

Regards,
Ionela