Picking a DITA 2.0 Subject to Create Examples for and to Write About (Whitepapers)

[Keith Schengili-Roberts <keith@ditawriter.com>]

Hello everyone:

My apologies for not posting this earlier, but I wanted to pass along the following information which may help people choose what DITA 2.0 subject you might want to write about in terms of creating example code and also as a white paper, either singly or collaboratively. 

A good resource which outlines everything is Kris Eberlein's presentation on the topic, available on SlideShare here: https://www.slideshare.net/kriseberlein/dita-20-a-not-backwards-compatible-release-249384017. It is also available as a YouTube video here: https://www.youtube.com/watch?v=WAw_hbFn1C0&t=5s. I also managed to download a machine-generated text capture of what Kris said in the presentation, which is attached to this email.  

In terms of possible topics to write about, page 13 of the presentation outlines things nicely:

I am hoping we can talk about this at our next meeting later today.

Cheers!

Auto-generated transcript of the YouTube video available at: https://www.YouTube.com/watch?v=WAw_hbFn1C0

good morning everyone
the webinar will begin shortly
well good morning and thanks for calling
in for today's webinar
about DITA 2.0 our first
release which is not backwards
compatible
I'm Kris Eberlein chair of the OASIS
did a technical committee and I really
want to welcome everybody to
today's call
just to give a brief overview of what
we'll be covering in today's
webinar we have a little bit of
information up front about
uh housekeeping and then we'll jump
right into
information about the technical
committee who designed it at 2.0
why we are doing a backwards and
compatible release
and the bulk of our time will spend be
spent looking at what's in DITA 2.0
we'll cover resources we are hoping that
everybody will download
beta versions of our DITA 2.0 grammar
files
available on both DTD and RNG
and take them for a test drive and then
finally we'll do questions if we have uh
depending on time
our plan will take we'll we'll
definitely take simple questions when
available today so please keep them
going in the chat but our real plan is
to handle those questions
on the 29th so
again our welcome and housekeeping we
will be recording
this webinar and it will be posted
shortly
on the OASIS channel at YouTube
all attendees are muted
and again please plan to attend our
follow-up webinar
on the 29th of June two weeks from today
at the same time
but do add questions to the chat
they'll be monitored during the session
and we'll take the simple ones today
time permitting and we will use more
complicated questions to plan for our
webinar on the 29th
so just to let you know in addition to
myself
there are three other members of the
data technical committee on today's
webinar we have robert anderson
a voting member who represents Oracle we
have deb bezants
a voting member who represents assand
and Chris Nitchie who is
a individual voting member
so with no further ado I think as most
of you know
data is designed and maintained by the
OASIS
data technical committee we have 16
voting members we meet weekly
and we really cover a very wide variety
of professional roles
in the ditty universe we're information
developers
architects content engineers managers of
departments
professors consultants application
developers
and we do come from if not
all parts of the globe from the us from
canada
from Germany and Israel
quick list here of the folks that spend
the time
each week and time
not in the tc calls working on driving
our work forward
and a big thanks to all of them who've
been very involved
in the DITA 2.0 release
and the critical reason that we are
doing this webinar it is
our first release that will not be
backwards
compatible and we have
planned for quite a long time to have
DITA 2.0 to be
a backwards incompatible release
because we knew we needed to pay
attention to
reducing our technical debt getting rid
of features that were
cumbersome overlapping really really
a little used and unnecessary
we needed to fix design mistakes and
do just the sort of general housekeeping
that has to happen to a standard
over time
that said we know that that a backwards
and compatible release
is going to make more work for everybody
it will require companies
that have their content and data to
make changes to their source and their
of course will be work
for you all vendors of data tooling
consultants who produce style sheets
anyone really in the DITA universe
who builds tools
or provides support to digI users and
that's why we're doing this series of
webinars
we really wanted to try to make sure
that folks knew what was coming with
DITA 2.0
early on so they could start planning
changes that need to be made to their
products
to their services we also
are we did a technical committee are
really looking for folks to test it at
2.0 to integrate it with your products
and provide feedback as early as
possible
so with no further ado let's start
looking at what's actually
in this release
and we'll start by looking at the
overall
structure it really will be delivered in
two packages
we are separating the base and the
technical content
and by technical content we are talking
about concept
task reference bookmap
the while ideally
we would be able we would be releasing
these two packages
simultaneously we know that the base
will be released
first and that the technical content
package will follow
on shortly thereafter I'm hoping that
there's not going to be more than maybe
a month or two difference between the
two releases
and the reason that we are clearly
separating the packages
and going into separate release modes
now
is that it's going to allow us more
flexibility in the future
for example we would have liked to have
made changes to
the DITA  1.3 troubleshooting topic
shortly after releasing 1.3 but we did
not want to have to make changes to the
entire base the entire package
and separating these packages will give
us more flexibility in the future if for
example we needed to introduce just
something that
had an impact on technical content
I know everybody is interested in what
what actually are the target dates so
I've given two dates here and I want to
stress that these are unofficial
these are not consensus dates from the
data
technical committee these are my
personal best guesses
as chair of the TC that will drive
perhaps as targets I would love to see
that we were it would be able to release
the base
perhaps in october 2022
and the technical content in december
2022 but again guesses targets
we'll we'll try to keep you posted as we
move along
and then of course I know everybody is
interested
we will of course have new DITA 2.0
doctype identifiers
for topics and maps
so it's always challenging with a new
release to
figure out the best way to group
the content our different features the
changes we're making
and in this deck they're simply
grouped along you know which are
architectural changes
where we have improvements to particular
features
or elements or domains new elements
new domains behind the scenes changes
which will have greater impact I think
for vendors and it does
for your typical data users who author
or produced it or architected a content
and then all the things that we are
removing
uh again I expect to see the removal has
hasn't it does have an impact for
vendors particularly we are no longer
going to be shipping XSD versions of our
grammar files
and changes of course the removal of
deprecated items
will affect source files
so let's launch right in here
architectural changes one of the things
we are doing is we're improving how
variable text is defined
variable text using keys was first
introduced in DITA 1.2
and over the course of releases 1.2
1.3 I think our result
our rules for resolving variable text
got
more and more complicated and one of the
clear
use cases we wanted to address here is
we wanted to make the rules for
resolving variable text
simpler for application developers
and we also wanted to make it much
clearer on how variable text should be
designed
as content authors
so our that was our use cases here
and as far as how we've implemented it
we are adding a new element called key
text
and we've established new rules
for how variable text defined using key
references
should be resolved and the priority
of different elements
the implications of this will be hits
to source files some DITA  1.x
markup will be invalid
we do not expect that
this will affect individual data topics
but this will involve changes to
key definition maps where keys that
define
variable text have been defined
the second large-scale architectural
feature
that is part of DITA 2.0 is we have
completely
redesigned chunking and this was
a proposal that was championed by robert
anderson
at Oracle I think we've known for a long
time that chunking was very complicated
there was a slew
of different tokens for the chunk
attribute that we're confusing
and it was difficult to implement
so the changes that we're making in
DITA 2.0
is we're removing the eight or so
previously defined tokens for the chunk
attribute
and replacing them with just
two new tokens combine and split
so again the implications here is
there will be changes needed to
source files to data maps the
DITA 1.x tokens for the chunk attribute
will not be recognized
and I'll just I will pause here since we
do have robert anderson on the call
robert is there anything you'd like to
add here about chunking
I don't think so just that we're really
hoping that this will be
simpler to use simpler to understand
simpler to implement all the above
thank you and folks in general
if you note here that that each of the
slides slides you look at
we do have a use case we have clear
defined implementation
we do have input implications
all of our planning work for DITA 2.0
has been focused
on uh being driven by use cases
trying to figure out ways of
implementing changes that are as simple
and straightforward as possible
and of course paying strict attention as
we go along
to what the implications of the changes
we introduced
to the standard would be for authors for
data content
for vendors
the next high level architectural change
is coming
is we are relaxing some specialization
rules
for all of us digital practitioners
who build document type shells and
specializations
and configurations for customers
we have long wanted to be able to
be more targeted with our
specializations
to add new specialized attributes and
make them
only available on certain elements
or to add new specialized elements
and make them only available in specific
targeted places and
we are enabling that for DITA 2.0
we're making it much simpler for people
to
introduce specializations and have them
be
more targeted on a spec
level that means that we are introducing
a
new some new terminology we are going to
be distinguishing between what is
document type configuration
i.e the configuration of a document type
shell
and what is element configuration the
configuration
of the content model or attribute lists
for specific elements
in general I don't think this has large
scale implications for
vendors but it does remove the need
that some vendors had to hack the one.x
OASIS grammar files to selectively add
attributes this should enable
anyone to be able to produce document
type shelves and specializations that
follow all of the OASIS guidelines
for how to code your document type
shelves
and specializations and this work was
championed by Chris Nitchie and
then I have taken over much of the
implementation work which
does not really hit the grammar files
but
had a very large impact on the
specification
i'll just pause here and say chris nichi
anything you'd like to add here not
particularly except
to say that this is something I've
wanted and did a since I've been
involved with it and
I'm excited that it's finally happening
you and me both
I think everybody who has built um
configurations for clients has
has wanted this
so this then takes us into talking about
the more specific
improvements to existing
parts features or elements in data
and we have some improvements to bookmap
we were very careful here to make all
these changes to bookmap
be backwards compatible we know people
have made a large
investment in bookmap and
initially we were hoping to introduce a
new type of publication map for DITA 2.0
we weren't able to do that but that is
potentially on the roadmap for a
follow-on did a 2.x release
so the changes we're introducing here
are simply to address the pain points
that we know people have experienced
I need to apply a did a veil to an
entire
book map and clear ways
to specify resource only objects
for example key definition subject
scheme maps
in a intuitive location in
the book map so we made some
minor changes to the content models of
bookmap and booklist
in order to permit this and we added a
new
element in the map group domain
called map resources which
solely has the purpose of containing
resource
only objects and has the
processing rule set by default
to resource only
that map group domain typically is
integrated into
both bookmap and regular data maps so it
will be available in both places for
people who are using
out-of-the-box OASIS shells
and this is work I've done
with also work from Eric Sirios of
Ixiasoft
another new change we're introducing is
simply making some enhancements to
flagging
using DITA vowels and
uh this is work that was championed by
robert anderson
of Oracle and
it enables folks
to add output class to either prop
or revprop in a dataval file and
specify that the output class
token as it exists
in the source content
will get passed through in html output
as a class value
to make it possible to style
that output class in
different ways robert anything you want
to add here
this one's a little tricky to understand
on the surface just because it involves
data valve flagging output class class
values and so
lots of terminology that sort of
overlaps and can be thrown but
basically it's a way to say you know if
I've had if I've tagged my
content with platform equals mac or
platform equals linux platform equals
windows
everything tagged with that I want a
special html class attribute out there
so I can then have complete style
control using css
so it's a more straightforward way to
say anything tagged with a particular
piece of metadata
put a specific html class on it to
add to whatever's already there
thanks robert appreciate that
another thing we've done and this is
work that was championed by scott hudson
at servicenow
is simply made the example element
available
in many many more places and this will
enable uh authors to be able to more
symmetrically tag content as an example
so where it was typically only available
as
a peer to section
in topics it now can be available within
sections
between paragraphs in definition lists
figures and more and I think the major
implication here is this probably will
require people to
make some changes to their style sheets
in css
particularly for how example is handled
when it is
within sections or as a peer to
paragraphs figures definition lists
a very simple change here for technical
content
we are allowing a phrase within the
content model
of glossary elements
which then will enable the use of the
highlight domain
in glossary elements particularly
subscripts
and superscripts very necessary and
a change needed by folks who are working
in
in physical sciences or medical fields
so simple straightforward I think very
little change for
vendors here
we also have made some fairly
wide scale improvements to the hazard
statement
and we have
this was introduced in DITA 1.2
and we knew that the content model
as introduced in DITA  1.2 was
not really aligned well with the
ansI 535.6
standard we also knew that contact
authors wanted to be able to use ordered
and unordered lists
when specifying how to avoid standard
and wanted to reduce the reliance
that they had on output class to get the
formatting they needed
to do things for example like enable use
of multiple hazard
symbols
so because this was rather
a full-scale um
change to hazard and statement I think
did a 1.x markup for
many hazard statements might be invalid
and need to be
restructured and that there probably
will be changes
to style sheets to css for how
hazard statements should be rendered in
authoring environments
if folks have built any wizards to
assist authors in inserting hazard
statements
those will need to be touched and
also because we've made some changes to
the specialization
base of some of hazard statement itself
and also of some of the sub elements
this will affect style sheets and i
don't have it mentioned here
but any data source
in which the class attribute values are
made explicit
will uh be affected here as
also will be the case for any other
changes where we have made changes to
the specialization base of
elements
another proposal here that I championed
was improving to
indexing
and this was largely driven again
by our desire to where we could
remove complexity make things simpler
make it easier for processors to build
reliable con
consistent support and
we in the implementation of this we have
removed the indexing domain
and added the index c and index c
l index c also elements which the domain
previously contained
to the base we've removed the index base
and index sort as elements
index sort as can be replaced by the
sword as element and we've improved the
specification content here
so I don't think there'll be a lot of
changes required here by vendors but
there is
sources changes to the data sources that
will crop up here
we did a pretty full scale enhancement
to
simple table this
is all backwards compatible in terms of
the data source but
we are what we are enabling is adding a
title to the simple table
and enabling row and column spanning
we did this for a number of reasons
first we really wanted to
ensure that DITA 2.0 had the appropriate
base
that Lightweight DITA requires
we also wanted to provide data
practitioners
with a more useful base from which they
could specialize table types
this proposal was driven and championed
by Carlos Evia
at Virginia Tech and
I do know that this will require
changes to data authoring tools
that pretty much across the board have
some
wizard and helping features for
inserting tables
and have menu items to make it easier
for
authors to merge table cells columns
rows
another change here that uh
comes in the technical content
package is that we're making changes for
steps
and we are enabling steps to nest
and removing sub steps and sub step
this will enable better reuse
of steps and step elements it will let
people have more than two levels of
steps
and will let people
more clearly defined in their subsequent
levels of steps whether they
should be ordered or unordered
so clear changes to data sources
data source will have to happen here for
content that
needs to be moved forward to DITA 2.0
uh if substeps were used and again this
was work championed by robert anderson
at Oracle and robert anything you'd like
to add here
not really other than this has been one
of the best received
even if somewhat trivial and design
changes that I've
talked about at various venues
I think any of us that have authored did
a content
and written a topic had some sub steps
and then suddenly realized we need to
reuse the content of those sub steps in
another topic
have felt the pain of the steps and
subsets
design and hopefully this change will
mitigate that
we have a change to the troubleshooting
topic
that was introduced in DITA 1.3 and
this is work championed by Don Stevens
at comm tech
and it addresses the fact that the
troubleshooting topic did not have a
clear semantic
place to add diagnostic information
so the implementation of this is
fairly clear and straightforward we're
adding three new elements diagnostics
which can contain either diagnostics
general or diagnostic
steps I will say that
this is one feature that we have
already gotten some feedback that we're
looking at that might
lead the technical committee to make a
slight change in the content model for
diagnostics
so stay posted for this one and
we're very interested in the feedback
that any vendors
any users who are test driving to the
2.0
might have to provide for us
we have a new include element
and this is really to handle inclusion
of
code
chris you are muted right now
okay there she goes I'm not I I saw a
message that the host had muted me
am I unmuted you are unmuted now okay
sorry about that I'm not sure exactly
what happened okay
and I'll just
start from the top of the slide since i
don't know when I got muted
we have a new include element with the
purpose of better handling
inclusion of code and text
and we are using the inclusion
element to as a new specialization base
for code ref svg ref
and mathmlref so this is championed by
chris nichi
and chris
any additional comments or elaboration
on this
yeah just a bit previously those
elements were based on xref
and so processors had to just know
that these references were special and
meant inclusion instead of link and so
the purpose of this really is
to allow processors and other data
practitioners
to create their own inclusion elements
that require no special plugins no
special code
for processors to recognize
excellent thank you very much for that
clarification and elaboration
another change here and this was
again really driven by functionality
that we needed to have in place
for Lightweight DITA is we've added
multimedia elements
to the base and we've just wanted to
make it much
simpler for content authors to add audio
and video to data topics we have
added audio and video elements
also three sub elements for controls
uh the implications here are really
changes to wizards
if they're wizards or menu and items or
icons for inserting multimedia
and this is work I've done but I do want
to
acknowledge that it is built on work
that chris nicci
did to develop a digital 1.3 compatible
domain
for multimedia
we have a new domain for alternate
titles
and I think the use cases here
affect both data practitioners and
a content author uh for practitioners we
wanted a clear way to be able to
specialize
elements for titles booked subtitles
window titles and for content and map
authors we wanted to make it
much simpler and straightforward for
how and where navigation titles are used
and rendered
so we're at we have added an alternative
titles domain
and the implication implementation
here really involves the following
changes
removing the title alts element
adding a new element called title alt
and making it available in prolog in
topics
and topic data in maps
uh the new title alt attribute is used
as a new specialization base
for search title for nav title for link
title subtitle and
title hint we are removing
lock title and the
table head element will replace the nav
title element
when it existed without lock title and
was simply there to
provide a hint to math map authors
as to what the topic topograph element
reference work champion by chris nichi
and chris please chime in here with
any additional information clarification
or elaboration
I'm not sure I've given your proposal
and your work
full justice here sure
just to say
similar to the inclusion proposal this
is a way for
alternate titles to be specified in a
standard way uh if you actually look at
the data source
for the DITA  1.3 specification you'll
see a lot of subtitles and
alternate titles that are implemented as
bookmap title alts or I forget exactly
how they're done but they're done in a
kind of odd way and I think that's a
fairly common practice
another thing that happens particularly
with bookmap is
uh when you have a bookmap that has a
title and then a subtitle
those are actually phrase elements
within the map title element
which means once again a processor has
to just know that this title is special
and these phrases within this title need
to be treated in a special way
this is a way to kind of try to get away
from
those workarounds around the limitations
of
not having an extensible alternate title
mechanism
by basically providing one it does
introduce its fair share of
incompatibility with DITA  1.3
uh because of things related to lock
title
and the way some of these elements
worked
and were part of the base vocabulary
in previous versions of data so there is
a little bit of a migration cost here
but at the benefit of vastly increased
flexibility
and extensibility and processability
of alternate titles in general
there's a typo in the last bullet there
it should be title hint rather than
table hints thanks robert
I will make sure I make that change
before we create a PDF has
posted on slideshare
I think we've covered this in our
discussion
again the implications the migration
costs here are
you know changes to data source required
changes to some style sheets although
we will be making I think style sheets
much easier in the future
and again if changes to data source
for any ccms that in the process of
storing data content
makes default attributes like the class
attribute
explicit in the source
we are adding a new emphasis domain
that simply contains a s
the strong and m elements by default
this will be added to all technical
content
topic types and provides
a alternative
alternative to the highlighting domain
for folks who want a more precise
and more semantic domain that is more in
alignment with HTML5
and this was work that was championed by
Keith Schengili-Roberts of Precision
Content
we have a new hardware domain
and this addresses use cases brought
forward
by authors who wanted to have clearer
markup to indicate hardware controls
and who wanted to be able to avoid using
output class
to distinguish between different types
of
controls so the hardware domain
has just two elements hardware control
and part number and by default
it is integrated into all technical
content
topics the technical committee really
spent substantial time on this proposal
we looked at the possibility of
containing uh of having this domain
contain more specific elements
but we really defaulted to trying
simply trying to provide the real basics
here
because we felt that so many companies
and
different industry verticals had
slightly
varying needs for what they would
actually be doing here
and that they would be better meant by
companies doing individual
specializations
of the elements in this domain
and this was work championed by one of
the newest
member tc voting members zoe lawson who
really has had a
big effect on DITA 2.0 and is a very
valuable
valued and valuable member
we have a lot of changes here that for
the purpose of previous
presentations to more of the user
community we
put together in this one behind the
scenes changes
and I do think however that these
changes
will have a large impact on vendors
on data practitioners on style sheet
developers
so I'll walk through these one by one
and try to
give more commentary about the the
implications here
we've made output class universal
um
all of the filtering attributes
audience platform products other props
are now created as attribute
specializations
of props so this of course really will
affect
all of all in any DITA 2.0 document type
shells
but we do expect that everyone will need
who everybody who has their own document
type shells
will need to create new DITA 2.0 based
document type shells
we resolved some inconsistent class
attribute values for shortdesk link text
and search title
and again a hit here to
style sheets and to any data source
that makes the class attribute values
explicit
in a similar vein we changed the
specialization base
for a few additional elements including
image map in order to
simply use a more correct
more appropriate base
we removed the xtrf and
xtrc attributes that were originally
added for debugging purposes we
know that some implementations and some
vendors have used those attributes for
their own purposes
and I think if that is the case for
your company for your implementation the
simplest thing to do
will be to specialize those attributes
and add them back to your document type
shells
we've split the syntax and programming
domain
so that the program the syntax
diagram elements are now in a separate
domain
we also remove the domains attribute and
replaced it
with a specialization attribute
and robert you champ championed
quite a large number of these proposals
so i'd like to ask if there's anything
you'd like to add or clarify or
elaborate on here
I think a lot of these are really
cleanup items um
like the first one output class is
available almost everywhere and did a 1
3 so this is just making it available so
we don't have people saying
but why isn't allowed here removing some
legacy stuff
splitting syntax and programming domain
that's just an acknowledgement that
a pretty significant number of those who
might want to make use of the
programming domain
don't actually use syntax diagrams so
it's splitting it into two
domains that just makes it easier to not
have that big chunk of syntax diagram
elements show up
while still using the others probably
the more noteworthy one is the domains
attribute
which is really uh language
simplification
it's the idea that the domains attribute
had grown over time
to fulfill a lot of theoretical ideas
that
didn't really well they weren't
practically speaking worth the cost
of the implementations and so it's
getting rid of most of what was placed
in that attribute
shifting over to the specializations
attribute which becomes for now just a
way to track specialized attributes
that's really the one case where we
needed to have domain information so
that processors can recognize
specialized attributes and how to handle
them
so for example that also will simplify
the creation of document type shells for
practitioners
who are including constraints or
expansion
modules in the document type shells
constraints will no longer
be required to add a token to
the old domains
now the specializations attribute
another thing we are doing and this will
be
have a my clear migration cost for
existing data content
is we are removing all items
that were characterized as deprecated
reserved for
future use or anything that we added by
mistake
and had to keep in the grammar files in
order to ensure backwards
compatibility and
this is one of the very first proposals
we approved
I championed this and it really was
very much with the intent
of reducing our technical debt getting
rid of cruft
and starting with a cleaner
fresher slate
so this will as I mentioned have a large
impact on folks existing
data source all the things
that were marked in DITA 1.2 and
1.3 or even since data 1.1
as deprecated all that markup will be
invalid
and I've listed out here the four i
think that will probably
have the most effect on existing content
and that is the alt attribute on image
which was replaced in detail 1.2
released in 2010 with the alt element
the nav title attribute on topograph and
topograph specializations
again also marked as deprecated in 2010
and replaced with the nav title element
the title attribute on map and
the print attribute
I would think for vendors who produce
ccms that this
might be a place that your customers
would be very much looking for
any possibility of scripting or
help that you might provide in an
automated way
for migrating data1.x topics to
DITA 2.0 with corrections to
this sort of markup
we do have a link here for how you can
get to
the 2.0 stage 2 proposal for this work
number 36 remove deprecated items
and if please if
any tools that are currently produced
insert the alt attribute or the nav
title
attribute please please make changes
and fixes there um
I I I'm only aware of of one
editing environment that is embedded in
a ccms that does by default
insert the alt attribute
we have some other cases where we simply
removed
certain attributes elements and domains
and these are things that
we thought were very little used or
were duplicates of uh something you
could do with existing
markup that's certainly the case with
the topic set and the topic set ref
elements
we are not we were not aware of anyone
using the delayed conraft domain
uh we removed a token from the type
attribute on
note the token being fast path again
one that we're not aware really of
people using
and finally we also removed copy 2
and the lock meta attributes block meda
had really
no defined meaning in the specification
and copy to although we know it is
heavily used
we felt copy2 was a
not really appropriate attribute for the
data specification
we are however replacing it with some
other architectural mechanisms and
markup that could signify
appropriate intent
by authors for
renaming of resources in
the processing
component of a data implementation
anyone on any tc member want to
elaborate
at all on copy to
i'll just note that I think the
replacement is
a little bit better designed it's a
little more flexible
so right now the copy to attribute as
designed was really
really designed around and tied to one
specific implementation or processing
design of content that's processed
sequentially through a processing tool
chain for generating html
and the replacement is based around the
resource id element has meant to be a
lot more flexible so that you can define
alternate anchors for html output files
but also for an anchor and a PDF
or for whatever other system you're
using
thanks robert
finally we are not shipping
XSD for DITA 2.0
we know that there are some tools out
there that rely on xst
and our suggestion is that you
simply generate monolithic versions
of the DITA 2.0 DTDs
if you need XSD and
our reason for not shipping it it really
comes down to a question of resources
and we just the technical committee did
not
have we didn't have the time and the
bandwidth
to keep developing and maintaining
XSD in addition to DTD and RNG
and the fact that DITA 2.0 was it you
know
it is a allowed us to break backwards
compatibility
enabled us to make this change
in a similar mode there are certain
specializations that were present
in DITA  one dot x releases that are not
present in 2.0 and here we have learning
and training
the machinery task topic and the
task prerequisites domain that was used
in the machinery task
topic and while we are not
including these as part of the DITA 2.0
OASIS standard
we will be updating these
specializations for DITA 2.0
and making them available in a OASIS
open
github repository
in much similar to why we're not
shipping XSD
we are not shipping these
specializations because we did not have
the
resources with the appropriate skill set
active on the DITA  technical committee
to keep these specializations maintained
up to date and in a healthy
state we're hoping the fact that we'll
be
making these available in OASIS open
github repositories
means that companies that use these
specializations
or practitioners that frequently use
them for clients
will be able to work with others
in OASIS open repositories
to update maintain
and improve these specializations OASIS
membership is not required
for people to work in OASIS open github
repositories
those are workplaces where the
technical committee can work with
folks that are not members of OASIS
and finally and I know we're getting
close to the top of the hour here i
really wanted to draw people's attention
to the resources we have available here
and first off and perhaps
the most important thing we have pack
tagged and
packaged beta versions of our ddd
and RNG files for both the base and the
technical content
and the urls here
um
are what you need for that
I'm hoping robert perhaps you can
you can make these urls available in the
chat
and then of course we
can have these included in a follow-up
email
and in the PDF of this webinar that
we'll make available shortly
on slideshare
again we've got a follow-up webinar
scheduled for
June 29th which is two weeks from today
at
the same time and this webinar will be
really dedicated to
questions and answers the questions the
comments
the thoughts and concerns that we got on
today's
webinar that we did not have time to get
to
and also I've given you an email here
did a chair at list.OASISopen.org
where you can send questions in advance
of the webinar on the 29th
so if you've got somebody else at your
company that you think needs to watch
this webinar of recording in this
webinar and then attend the follow-up
session
we've made this possible again the
recording will be available
as soon as possible perhaps even today
and we've got the link here to
register for the webinar and
dee or jane at OASIS if you could get
that
webinar registration url available
in the chat that would be I would really
appreciate that
and finally uh we do have uh we've got a
very few minutes here for questions
and I'll ask Deb
I know you were monitoring chat and q
a are there some questions that we
perhaps could
address in in the next uh
three or four minutes um
yes robert did answer but um
one question came in can you explain the
book map
change auto generated updates
and I think simply what we enabled here
was adding
modifying the content model of book
lists
in order to be make it possible for
somebody to
indicate clearly to a processor that
this would be a place where there should
be an
automatically included um
list of changes and we can address that
in more detail on the 29th
also
another question and I think
you've already answered this was
why are XSDs removed and DTD's still
supported
well we we RNGs
are our normative format for our grammar
fonts
we also know that there are
only one or two applications out there
that currently support
RNGs that most of the products in the
DITA universe
require DTDs a handful require excess
dues
so that is why we are continuing to do
to support DTDs because
the number of tools that require xst's
are substantially smaller
that was the place that we just where we
had to make a cut
and we do very much hope that vendors of
data tooling
will start introducing certainly please
consider for the next release of your
product for release of the product that
supports
DITA 2.0 consider whether your product
could support
the data grammar files in RNG format
it is much easier for practitioners to
create document type shells to create
constraints
to create expansion modules and to do
specializations in RNG
and it is our normative format
and chris I'll just note if it helps
that question about XSDs came in before
you got to the slide so yeah
yeah one more question
oh do you want to take it or it is top
of the hour
it is top of the hour so I really want
uh very much to thank everybody and
please register for the webinar on
the 29th
questions that came in today that we
didn't have time to get to we will take
them
and we will also take any questions that
you forwarded
to the chair
email address so
I want to thank everybody and um
I will stop sharing right now and thanks
again for
for debuzants for robert anderson and
Chris Nitchie
for taking additionally taking part in
this webinar
they'll also be present on the 29th