Re: [dita] Issues in DTDs checked into SVN

[Robert D Anderson <robander@us.ibm.com>]

> can do). When you say "bad headers" do you simply mean that the headers
> don't match the original 1.2 headers for the .ent files?

I spot-checked the ones in the base directory, and they all seemed to be literal copies of the header from the .mod file. As a result, the comments (such as Updated X on date Y) all reflect changes made in another file, and they all list the public ID / system ID for the mod file. For example, in the file hazardstatementDomain.ent, we have this sequence of comment lines:
<!--  Refer to this file by the following public identifier or an  -->
<!--       appropriate system identifier                           -->
<!-- PUBLIC "-//OASIS//ELEMENTS DITA Hazard Statement Domain//EN"  -->
<!--       Delivered as file "hazardstatementDomain.mod"                -->

The odd idElements entity really isn't a problem - we've had more annoying entities in the past - I'm mostly just calling that out as a difference between the actual 1.2 and SVN 1.2. I think most of the other items are more urgent for fixing.

Thanks -

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)

Eliot Kimber <ekimber@contrext.com> wrote on 10/20/2014 09:46:54:

> From: Eliot Kimber <ekimber@contrext.com>
> To: Robert D Anderson/Rochester/IBM@IBMUS, DITA TC <dita@lists.oasis-open.org>
> Date: 10/20/2014 09:47
> Subject: Re: [dita] Issues in DTDs checked into SVN
>
> I'll take a look at all of these. I have documented variances from the
> original 1.2 declarations that are an unavoidable consequence of
> generating the DTDs and XSDs, but most of these do no fall into that
> category, I don't think.
>
> On issue 13, headers for .ent files, that's a problem: since the RNG does
> not have separate mod and ent files, there's only one header comment in
> the RNG source, so not obvious how to produce different headers for .mod
> and .ent files unless we include both headers in the RNG source (which we
> can do). When you say "bad headers" do you simply mean that the headers
> don't match the original 1.2 headers for the .ent files?
>
> The idElements pattern in the RNG is required in order to handle the
> RNG-specific rules for patterns involving elements with ID-type
> attributes. I can ensure that those patterns don't get reflected in the
> generated DTDs and XSDs.
>
> I'm still working out details of constraint module generation: there's
> some complexity there. The current code is not always generating correct
> DTD declarations. It may be necessary to special case all constraint
> module generation, I'm not sure yet.
>
> I'll add these issues as cards in the Trello board I set up for the
> remaining grammar generation issues:
> https://trello.com/b/y42J0sEq/rng-to-dtd-and-xsd-conversion
>
> Cheers,
>
> E.
>
> —————
> Eliot Kimber, Owner
> Contrext, LLC
> http://contrext.com
>
>
>
>
> On 10/20/14, 9:27 AM, "Robert D Anderson" <robander@us.ibm.com> wrote:
>
> >Hi,
> >
> >After Kris found the DTD issue with the (map mapgroup-d) token last week,
> >I realized that the copy of DITA 1.2 checked in to SVN did not match the
> >copy of DITA 1.2 shipped by OASIS. I did some comparison of the shipped
> >DITA 1.2 and SVN 1.2, and found many inconsistencies. Everything I've
> >listed below is also an issue for the DITA 1.3 DTDs. I found all of these
> >issues by comparing 1.2 level DTDs - not comparing the RNGs - so this
> >presumably mixes RNG issues with conversion tool issues, and also means
> >that this testing did not cover anything new to 1.3.
> >
> >1. All embedded files are missing public IDs. These have been present
> >since 1.0, and in 1.2 we explicitly made all internal public IDs use
> >version-specific values. This was done by TC request, and they should be
> >added back.
> >
> >2. Several entity declarations have been removed from the DTD. Some are
> >unlikely to cause problems but all could potentially be referenced in
> >specialized DTDs (I know of DTDs that reference the first one):
> >- %rel-atts in topic.mod: deprecated in 1.2 but left in for backwards
> >compatibility
> >- %hazard.cnt used to set content models in hazard domain
> >- In the tblDecl.mod, unlikely to cause problems but for completeness:
> >-- Entity %bodyatt; removed from table attribute list - was empty,
> >present as part of OASIS table model
> >-- Dropped entity %tbl.table.name; (value was "table") -- previously used
> >to define the element name
> >-- Dropped entity %titles; (value was "title?") -- it was declared but
> >unused in OASIS DITA 1.2
> >
> >3. The error Kris found in the mapgroup domain token is still present in
> >the glossref domain and learningMapDomain tokens (both claim to be based
> >on topic).
> >
> >4. The domain token for learningAssessment has changed - not sure if this
> >is intentional - from "(topic learningBase+learningInteractionBase-d
> >learningAssessment)" to "(topic learningAssessment)"
> >
> >5. In ditabase.dtd, the declaration of <dita> has dropped several
> >attributes. The following are present in DITA 1.2 but missing in DITA 1.3:
> >%arch-atts -- @ditaarch:DITAArchVersion, @xmlns:ditaarch,
> >%debug-atts -- @xtrc, @xtrc.
> >Related: in 1.3 we've added @translate and @dir to the existing @xml:lang
> >-- I think these should be added using the common localization-atts group
> >rather than declared independently?
> >
> >6. The task domain entity (topic task) has been dropped from
> >ditabase.dtd, task.dtd, and machineryTask.dtd
> >
> >7. glossary.dtd is broken: it is supposed to redirect to glossentry.dtd
> >but actually does nothing
> >
> >8. The topic containment entities are broken in learningContent.dtd. The
> >learningContent element previously allowed lots of children, currently
> >1.3 changed this to only allow <no-topic-nesting>:
> >1.2 as shipped: <!ENTITY % learningContent-info-types "((concept | task |
> >reference | topic)*, (learningAssessment)?, (learningSummary)?)">
> >1.2 and 1.3 in SVN: <!ENTITY % learningContent-info-types
> >"no-topic-nesting"
> >>
> >
> >9. Related - the content model for <topic> inside the learningContent
> >doctype has also changed, pretty sure this was not intentional. DITA 1.2
> >shipped with this declaration in learningContent.dtd:
> ><!ENTITY % topic-info-types "(no-topic-nesting)?">
> >The SVN copies do not declare this entity, and as a result the default is
> >picked up, and <topic> now allows nesting of <topic>
> >
> >10. The strictTaskbodyConstraint domain entity name is invalid. The name
> >of the entity name has changed from "taskbody-constraints" to
> >"strictTaskbody-constraints". This will break any user of the constraint,
> >and also violates the spec (spec requires the entity use the literal
> >element name). I believe this error was introduced recently, it was not
> >in my copy of SVN until I updated on Friday.
> >
> >11. The map.mod module drops the default empty declaration of
> >included-domains (it is still in topic.mod).
> >
> >12. Every element has its attribute entity (such as alt.attributes)
> >declared twice. Strictly speaking this does not introduce errors but
> >really needs to be fixed (it's confusing and looks bad).
> >
> >13. Many of the DTD modules have bad headers (every ENT file I spot
> >checked and several of the MOD files). The ENT files appear to grab their
> >headers (including public ID info) from the equivalent MOD file.
> >
> >Nit-picks that we would fix if creating these by hand:
> >- In topic.mod, the entities "info-types" and "topic-info-types" are each
> >declared twice
> >- In machinery taskbody constraint, %prelreqs and %closereqs are each
> >declared twice
> >- DITA 1.2 /1.3 in SVN has added an entity idElements; it's empty and
> >unused, so not sure of the purpose
> >
> >Robert D Anderson
> >IBM Authoring Tools Development
> >Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)
>
>