// Changed by X on date Y for bug Z start
...
// Changed by X on date Y for bug Z end

That is what revision control is for. Use commit messages that describe the reason for the change and generally make commits that change only one thing at a time. That’s my preference over change history in code comments.

There is no real reason to change the current package name, but you have to admit that e.g. net.sf.dita-ot or org.xml.dita would have been more suitable.

The version scheme I’d prefer to see is what e.g. OSGi uses. That is, major.minor.micro.qualifier. Thus the current DITA-OT version number would be something like 5.2.0.M6. I naturally wouldn’t change version numbering at this release, but instead of making the next release 1.5.3 I would make that 2.0.0. It would have made sense to do it at this stage to coincide with DITA 1.2 support, but it’s too late now. Anyhow, then the releases could reserve the third version number for bug releases (which DITA-OT doesn’t really ever release), and use the milestone version as the fourth part.

The choice between schema languages was easy, RELAX NG has everything I need and is pleasant to write. In addition, oXygen can use the documentation in the schema, so all the better. I used Trang to convert the original DTD to RELAX NG, then just edited the filed manually and occasionally with XSLT.

The code is hosted at GitHub, licensed under GPL. It’s very much a work in progress, but it works for me.

• topic.dtd
• concept.dtd
• task.dtd
• reference.dtd
• glossary.dtd
• ditabase.dtd
• map.dtd
• bookmap.dtd

All in ZIP file.

⌥

option

⌘

command

⌃

control

Will that make a difference in my life, ever? Probably not, but I think it’s still cool that I could use those characters in text if I wanted to. As in, instead of writing press Option-Command-Esc, I would write press ⌥ ⌘ Esc. Yey!

MIME media type name:

application

MIME subtype name:

dita+xml

Required parameters:

None.

Optional parameters:

charset:

This parameter has identical semantics to the charset parameter of the application/xml media type as specified in [RFC3023].

Encoding considerations:

By virtue of DITA content being XML, it has the same considerations when sent as “application/dita+xml” as does XML. See RFC 3023, section 3.2.

Security considerations:

[Something about conref.]

Interoperability considerations:

[Haven't thought about this yet.]

Additional information:

Magic number(s):

There is no single initial octet sequence that is always present in DITA documents.

File extension(s):

DITA documents are most often identified with the extensions “.dita” or “.ditamap”.

Macintosh File Type Code(s):

TEXT

Intended usage:

COMMON

Author/Change controller:

The DITA specification is a work product of the OASIS’ DITA TC. The OASIS has change control over these specifications.

This would allow us to change the definition of the format attribute e.g. in links into being a MIME Media Type, not a file extension.

Update

Three years later a MIME Type was added in DITA 1.2.

Note: There is a new version of the generator at DITA DTD Generator.

Change History

ISO Schematron schema for DITA 1.1 and 1.2 that handles cases that DTDs or XML Schemas cannot control. The current implementation covers for example:

• nesting links inside links or titles
• deprecated attributes and attributes
• attributes not intended for author use.

Download latest version from GitHub. The schema is released under GNU Lesser General Public License.

Usage

The schema comes in two parts,

• dita-1.1.sch
• dita-1.2.sch

for different DITA versions. The schema has three phases:

specificationMandates

constraints in the DITA language specification prose

recommendations

constraints and recommendations in the DITA language specification prose

authoringRecommendations

recommendations for authors

Change History

See GitHub downloads for latest releases.