Re: [dita] "The DITA iceberg" presentation at DITA Europe 2016 -- how RNG focus could help

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

> If the heavy lifting of doing specializations and other schema work
> is done in RNG, and the DTD is used only for tools that do not
> support RNG, does it matter whether the DTD is a flattened,
> monolith? In that scenario, the DTD is like object code; only read
> and processed by a machine.

For what it's worth (if anything), that's the conclusion I came to in my "ditasplainer" blog post, which I wrote after find out about a company paying a lot of money to create a modular XSD version of their modular DTD. RNGs weren't even in the equation yet, but the net result is the same. For an individual, team, or company, if one format can just be generated (but maintained elsewhere), why does it matter if the generated one is modular?
http://metadita.org/toolkit/ditasplainer.html

To be clear, my argument only applies to end users of DITA (today) and to DITA 2.0 (in the future) -- OASIS DITA 1.3 definitely required the TC to deliver modular versions in all 3 formats.

Regards, Robert D. Anderson DITA-OT lead and Co-editor DITA 1.3 specification, Digital Services Group
E-mail: robander@us.ibm.com Digital Services Group
11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA

<dita@lists.oasis-open.org> wrote on 11/18/2016 11:48:54 AM:

> From: Richard Hamilton <hamilton@xmlpress.net>
> To: Kristen Eberlein <kris@eberleinconsulting.com>
> Cc: DITA #61009021 <dita@lists.oasis-open.org>
> Date: 11/18/2016 11:49 AM
> Subject: Re: [dita] "The DITA iceberg" presentation at DITA Europe
> 2016 -- how RNG focus could help
> Sent by: <dita@lists.oasis-open.org>
>
> If the heavy lifting of doing specializations and other schema work
> is done in RNG, and the DTD is used only for tools that do not
> support RNG, does it matter whether the DTD is a flattened,
> monolith? In that scenario, the DTD is like object code; only read
> and processed by a machine.
>
> Also, though probably a minor point for most people, I was able to
> get emacs nxml mode (which uses RNC) working with DITA, and I’ve
> been editing Leigh White’s DITA for Print second edition with emacs.
>
> Not much (read any:-) support for advanced features, but it works
> fine for editing individual topics, if you are comfortable looking
> at angle brackets:).
>
> It works particularly well for me, because I’ve been using emacs
> since the 80s:-).
>
> Dick
> -------
> XML Press
> XML for Technical Communicators
> http://xmlpress.net
> hamilton@xmlpress.net
>
>
>
> > On Nov 17, 2016, at 22:28, Kristen James Eberlein
> <kris@eberleinconsulting.com> wrote:
> >
> > Hi, Tom -- See below.
> >
> > Best,
> > Kris
> >
> > Kristen James Eberlein
> > Chair, OASIS DITA Technical Committee
> > Principal consultant, Eberlein Consulting
> > www.eberleinconsulting.com
> > +1 919 682-2290; kriseberlein (skype)
> >
> > On 11/17/2016 5:41 PM, Tom Magliery wrote:
> >> Regarding Robert's objections list:
> >>  
> >> 1. There will also be pushback from users/vendors of tools that
> do not natively support RNG. There will probably continue to be
> issues with the automatic generation of DTD/XSD from RNG.
> > <kje>Most tools do NOT natively support RNG. The only ones that I
> am aware of are oXygen and DITA-OT. But -- it should be really easy
> to generate DTD from RNG if we are willing to have as the end result
> a flattened, monolithic, single-file DTD.</kje>
> >>  
> >> 2.  " in DITA 1.0 days we thought [exchange of vocabulary
> modules] would happen all the time, but I haven't seen it happen
> much in practice. "
> >> Isn't that why we have L&T, and machineIndustry, and
> Troubleshooting, and ... ?
> > <kje>Those are good examples of widely-used specializations
> distributed by the TC as part of the standard. I think that by
> "exchange of vocabulary modules" Robert means something like the
> following scenario:
> >
> > Company A: We built a cool domain to document GoofyDoc!
> > Company B: Can I have it? I want to drop it today into the shells
> for our authors ...
> >
> > I think we see a lot of the above between consultants and company
> IAs testing on the file system or in a test environment.
> > </kje>
> >>  
> >> mag
> >>  
> >>  
> >>  
> >> From: Robert D Anderson [mailto:robander@us.ibm.com]
> >> Sent: Thursday, November 17, 2016 2:24 PM
> >> To: Kristen James Eberlein
> >> Cc: Tom Magliery; DITA TC
> >> Subject: Re: [dita] "The DITA iceberg" presentation at DITA
> Europe 2016 -- how RNG focus could help
> >>  
> >> Hi all,
> >>
> >> I think this point needs a lot of thought / discussion:
> >>
> >> >> Maybe we need to move to a model where we encourage folks to
> configure, specialize, and constrain in RNG -- keeping to all the
> rules driven by modularization -- but them convert the RNG to a
> monolithic DTD for use in production. Yes, this will limit ease of
> interchange, but ...
> >>
> >> This where I've been going in my head. It was prompted by the
> shock I went through finding people were (at great cost) maintaining
> modular XSDs and modular DTDs for the same grammar, simply to follow
> the spec grammar rules.
> >>
> >> Here's my thinking, which hopefully flows logically:
> >>
> >>    • Some constraints are relatively easy in DTD (for those who
> can already understand DTD). Others have a clear pattern, but are
> hard. Many get so big as to be impractical (removing <ph> or <pre>
> from every context).
> >>    • The entities we have to use in DTD are just plain ugly.
> They're required by DTD rules if we want specialization/constraints
> to work. But they're ugly.
> >>    • Basic DTD rules also require that we order many files in a
> specific way. We lay those out as rules in our spec, because anybody
> doing this has to follow them or the DTD breaks. For other files,
> the order is less important, but we put rules on those too. Because
> saying "Put these 10 things in this order" is better than saying
> "Put these 7 things in order, then this one somewhere between 0 and
> 3, and these somewhere between 5 and 7".
> >>    • Constraints in RNG are easy. If you know XML but not RNG,
> the patterns are easy to learn. I mean ridiculously easy, compared to DTD.
> >>    • In a world where we all write constraints in RNG, no single
> constraint is out of bounds simply because it's impractical.
> >>    • If you (like we at OASIS) develop in RNG, everything else
> can / should be generated. Doing otherwise would be like developing
> content in DITA, but maintaining an HTML version in parallel.
> >>    • Once it's generated ... the organization of the DTD / XSD
> shouldn't matter to the average DITA user. The use of entities, the
> number of files are irrelevant, because you'll never look at it.
> It's almost certainly more efficient to have a single file for use
> in your tools; it's certainly less confusing.
> >>    • If we push this as a best practice with 2.0 ... constraints
> become almost trivial. Specialization isn't trivial, but it's
> certainly far easier than in DTD or RNG. Even those who cannot use RNG win.
> >>
> >> Point #5 above is the one that most closely relates to the
> iceberg problem. If base DITA with no domains is too much for you,
> today there are practical limits to what you can cut away, and still
> Follow The Rules. With RNG, that practical limit goes away. There's
> now a straightforward, easy to follow pattern for any constraint. At
> least, that is my understanding, and the basis for this entire note.
> >>
> >> One outcome from this could be for DITA 2.0 to get away from
> modular DTDs and XSDs entirely, but keep our rules / instructions
> for modular RNGs.
> >>
> >> There are reasons not to push everybody to RNG as their "source",
> but I'm wondering if the advantages outweigh the objections.
> >>
> >> The following list of objections is probably not be exhaustive,
> but they're sure to come up:
> >>    • Those with extensive DTD or XSD based specializations would
> clearly have a harder time upgrading to 2.0. Either we'd have to
> ship a modular copy of DTD / XSD just to allow this, or else they'd
> have to convert their modules to RNG.
> >>    • Those trying to stay with modular DTD/XSD would no longer be
> able to easily exchange vocabulary modules. That said - in DITA 1.0
> days we thought this would happen all the time, but I haven't seen
> it happen much in practice.
> >>    • People already comfortable with DITA DTDs (there are a few
> of us) or XSDs would have to learn a new way of working. But ...
> that seems reasonable after 15 years, especially when RNG is so much easier.
> >>    • People who spent weeks making a constraint to remove <ph> in
> XSD might be annoyed once they learn how easy it is in RNG. Of
> course that's probably an argument for the switch rather than a
> reason to oppose it...
> >>
> >> I'm curious to hear what others would think about this. If the
> logic doesn't make sense, I'll blame jetlag, having returned last
> night from Munich. As mentioned, I've been thinking about this for a
> while, so it's also possible I jumped over some logical step that I
> had wrestled with some weeks ago.
> >>
> >> Regards,
> >> Robert D. Anderson
> >> DITA-OT lead and Co-editor DITA 1.3 specification,
> >> Digital Services Group
> >>
> >> <Mail Attachment.png>
> >> E-mail: robander@us.ibm.com
> >> Digital Services Group
> >> <Mail Attachment.png>
> >> 11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA
> >>
> >>
> >>
> >> <Mail Attachment.gif>Kristen James Eberlein ---11/17/2016 02:46:
> 17 AM---Maybe we can separate the pain points raised in Leigh's
> presentation and possible solutions: Pain p
> >>
> >> From: Kristen James Eberlein <kris@eberleinconsulting.com>
> >> To: Tom Magliery <tom.magliery@justsystems.com>, DITA TC
> <dita@lists.oasis-open.org>
> >> Date: 11/17/2016 02:46 AM
> >> Subject: Re: [dita] "The DITA iceberg" presentation at DITA Europe 2016
> >> Sent by: <dita@lists.oasis-open.org>
> >>
> >>
> >>
> >> Maybe we can separate the pain points raised in Leigh's
> presentation and possible solutions:
> >> Pain points
> >>
> >> 1. Our starter set of DTDs has more in it than many people want.
> >> 2. Many people don't understand that they can configure their own
> document-type shells; they think the start set of shells ARE DITA.
> If they know that they can configure shells, it still might be too
> troublesome to implement them. For example, a small company with a
> handful of writers using version control on the file system will
> have to install doctype plug-ins whenever they upgrade their
> authoring tool or DITA-OT instance.
> >> 3. Constraints are ridiculously time consuming to implement in
> DTDs. It's relatively simple to subset a domain -- but to remove
> base elements (for example, <pre>) requires constraining every
> element that can contain the base element. It's much easier in RNG.
> And it just doesn't really work in XSD.
> >>
> >> Possible solutions
> >> 1. DITA 2.0 gives us the opportunity to modify what we include in
> the starter set of shells. We also could distribute other sets of
> shells ... I suspect that if we wanted to entertain that, we should
> NOT have them be part of the standard. We could "release" them as a
> package associated with a ZIP file.
> >> 2. We need to do more education about configuration.
> >> 3. Maybe we need to move to a model where we encourage folks to
> configure, specialize, and constrain in RNG -- keeping to all the
> rules driven by modularization -- but them convert the RNG to a
> monolithic DTD for use in production. Yes, this will limit ease of
> interchange, but ...
> >> 4. Drop support for XSD.
> >> Best,
> >> Kris
> >>
> >> Kristen James Eberlein
> >> Chair, OASIS DITA Technical Committee
> >> Principal consultant, Eberlein Consulting
> >> www.eberleinconsulting.com
> >> +1 919 682-2290; kriseberlein (skype)
> >>
> >> On 11/16/2016 10:45 PM, Tom Magliery wrote:
> >> I love the idea of a smaller "standard DITA", and I look forward
> to months/years of entertaining discussion while "what's in" gets
> hammered out.
> >>
> >> mag
> >>
> >>
> >> -----Original Message-----
> >> From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org
> ] On Behalf Of Kristen James Eberlein
> >> Sent: Tuesday, November 15, 2016 11:19 PM
> >> To: DITA TC
> >> Subject: [dita] "The DITA iceberg" presentation at DITA Europe 2016
> >>
> >> Attached is a PDF from a session done by Leigh White, IXIASOFT, at this
> >> year's DITA Europe conference. (I'll follow up later with some
> >> additional PDFs from other sessions.)
> >>
> >> I'd like to ask TC members to read and consider it; I'm looking forward
> >> to discussion on the list.
> >>
> >>
> >>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >>
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>