I agree that vocabulary exchange will not be possible for #3 as long as they are unwilling to migrate to RNG. However, I claim that the benefits of dropping DTD and XSD modularity outweigh dissapointing #3 because it is essential for us to simplify grammar configuration and constraints for 2.0. DTDs are not flexible enough to allow this in a way that is understandable to most Information Architects.
For example, one could use a common RNG module to apply common domain configuration across a number of topic shells. This would be highly desirable for the technical content grammars and the learning grammars. Similarly, common constraint overrides could be packaged and applied. This can't be done as long as RNG components have to be instantiated as DTD components.
On Fri, Nov 18, 2016 at 9:21 AM, Kristen James Eberlein <> wrote:
Of course, folks can exchange RNG vocabulary modules and
regenerate the DTDs -- Assuming that they will be willing to move
to RNG for their design work.
It just begs the question of how many folks will do that,
especially companies with existing modular DTDs.
Can we tease out the players for a possible future scenario?
New DITA implementations that use OOB OASIS-shipped shells
New DITA implementations that build RNG-based shells and
auto-generate DTDs
Existing DITA implementations with DTD- or XSD-based shells --
Not interested in recreating their stuff in RNG
In this scenario:
1 & 2 won't be able to provide #3 with modules, unless
they have the ability to use Eliot's tool.
3 won't be able to provide 1 & 2 with modules. Period.
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/18/2016 9:38 AM, Bob Thomas
wrote:
At the risk of pointing out the obvious, vocabulary
module exchange can still be done RNG. Then, if DTDs are
required they can be regenerated with exchanged module in place.
Bob
On Thu, Nov 17, 2016 at 11:32 PM,
Kristen James Eberlein <>
wrote:
I think we'll need to carefully tease out costs and
benefits when considering proposed solutions.
This is one of the reasons that I want people to be
careful to list pain points (possible future
requirements) separately from possible solutions.
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:44 PM, Rob Hanna wrote:
Good
day, Robert.
I
am unfamiliar with RNG but it sounds
promising. I’m slightly concerned about your
comment that moving to RNG could make the
exchange of vocabulary modules difficult. I
assume this is because the DTD is completely
flattened. In converting the RNG to a DTD,
could it be possible to flag elements
belonging to vocabulary modules and generate
separate DTDs to facilitate exchange? I see
that the concept of exchange goes back to the
headier days of DITA 1.0 but I still have hope
that we will get there someday soon.
Cheers,
Rob
Hanna
From:
[mailto:]
On Behalf Of Robert D Anderson
Sent: November 17, 2016 5: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
E-mail:
Digital
Services Group
11501
BURNET RD,, TX, 78758-3400, AUSTIN,
USA
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 <>
To:
Tom
Magliery <>,
DITA TC <>
Date:
11/17/2016
02:46 AM
Subject:
Re: [dita]
"The DITA iceberg" presentation at DITA Europe
2016
Sent
by: <>
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: [mailto:] 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
--
Bob
Thomas
+1 720 201 8260
Skype: bob.thomas.colorado
Instant messaging: Gmail chat ()
or Skype
Time zone: Mountain (GMT-7)
--
Bob Thomas
+1 720 201 8260
Skype: bob.thomas.colorado
Instant messaging: Gmail chat () or Skype
Time zone: Mountain (GMT-7)
