Robert D. Anderson
DITA-OT lead and Co-editor DITA 1.3 specification,
Digital Services Group
Digital Services Group
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] DITA 2.0: How might we reorganize (reformulate?) the spec for DITA 2.0
I think what I really meant was coding practices (the term used in DITA 1.3).
We have a lot of critical rules around specialization - here is how you extend an element, here are the rules for what you can do with it. Those do not (necessarily) have any connection to the grammar files. That is - conceptually, when I specialize <ol> to <steps>, there are a lot of things I can do and and a lot of things I cannot do. Those rules are true regardless of what grammar format I'm using (XSD, DTD, RNG, or any other rule format). The rules are true whether my particular DTD implementation is modular, or optimized in a single file. They're even true in the (abstract and rather impractical) case where you don't even have a grammar file.
Those are now in section 2.5.3 (2.5 as a whole covers specialization, constraints, generalization, and configuration).
All I meant was to highlight that this is different from constructing the rules themselves (that is, different from the DTD/XSD/RNG coding practices). In DITA 1.2 these things were all jumbled together in different parts of the Architectural Spec. In 1.3, they're distinct, which is an improvement. In a larger reorganization, I'd hope to maintain that distinction, treating the rules on how to extend + constrain DITA as separate from the rules for one specific grammar format.
| Sorry for the confusion, Robert D. Anderson | |
| E-mail: robander@us.ibm.com Digital Services Group | |
| 11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA | |
"Tom Magliery" ---09/08/2016 01:01:29 PM---What do you mean by "Grammar file construction"? That sounds like it would be something under the spI wanted to follow up on the discussion from Tuesday, specifically regarding the suggestion that (I'm pretty sure) came from Chris Nitchie.
The suggestion there was about changing how we think about and publish the spec. Rather than using a hard-to-define separation of "Architectural spec" versus "Language spec", much of our content could be organized much more logically into Processing and Grammar.
As I said on the call, I really like that idea. Kris and I found during 1.3 editing that it could be very difficult to make a distinction between what was "Architecture" versus what was "Language". That difficulty doesn't entirely go away with Processing and Grammar, but I think those groupings go a long way to helping us better organize the content. That said - those two distinctions don't cover everything in the specification. I expect that if we make that sort of reorganization, we'll end up with several better focused sections.
I can think of a few good candidates for other major sections of a 2.0 spec, based on sub-sections of the current architectural specification:
- Addressing
- Specialiazation and modularity
- Grammar file construction
Are there any suggestions for additional types of content that exist in the spec (and should continue to exist)? Alternatively, do any of the sections I've listed seem like the wrong direction?
| Regards, Robert D. Anderson |  |
| E-mail: robander@us.ibm.com Digital Services Group | |
| 11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA | |
| |
Kristen James Eberlein ---09/06/2016 09:57:56 AM---DITA 1.0: Separate architectural spec and language reference DITA 1.1: " "[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]