I have been doing some tracking on LWDita but now am looking at how it all fits with full DITA and how to implement it in XDocs.
I reviewed DITA to derive “fundamental DITA” and then looked at the LWDita DTDs on GitHub.
It seems that LWDita is fundamentally DITA. For one thing, in XDITA there seems to be a notion of class and class attributes. Might be good to formalize what the “DITA fundamentals” are. For example likely you don’t need branch filtering and scoped keys to be “fundamental DITA”.
I have a couple of questions at this point.
1. How do we reconcile two definition of <topic> - the lwtopic and the original DITA topic?
Perhaps <lwtopic> might be a better tag.
Or perhaps the existing topic should become <generic-topic> - the backward compatibility problem being daunting. Although I have always thought converting from one topic type to another should be easier (tooling?)
Is there a simple way to make sense of this issue of two things in the DITA universe called <topic>?
2. With HDITA and XDITA would it be fruitful to formalize a “DITA Infoset” or “DITA DataModel”. Which is similar in idea to XML Infoset but with DITA architectural constraints.
Then you can say HDITA,MDITA and XDITA are serializations of the DITA InfoSet. This was useful when designing XQuery which defines an XQuery/XPath Datamodel which is similar to XML Infoset – see https://www.w3.org/TR/xquery-30/#id-data-model-generation
And discussion of serialization – see https://www.w3.org/TR/xquery-30/#id-serialization
The abstract idea is you parse (de-serialize) an XDITA, HDITA or MDITA file into a DITA Infoset and processors work on the DITA InfoSet.
From a DITA InfoSet you can serialize to XDITA, MDITA or HDITA.
It may be more practical to map directly to an XML file – but you could make DITA Infoset easy to map to XML.
Not sure about this one, but thought to put it out there if anyone else sees value in such a “DITA Infoset” formalism now or down the road.
Thats all for now.