RE: [dita] Specialization support: a core philosophical issue

[Michael Priestley <mpriestl@ca.ibm.com>]

Hi Eliot,

For context, check out the proposed
refactoring of the spec for 1.2: a core architectural spec, language spec,
and processing spec that documents topics and maps and core behaviors only
(no specializations), and then a separate set of specification documents
for each of the groupings of specializations.

http://wiki.oasis-open.org/dita/Draft_1.2_TOC

I should have included the link in the
first note - it's what we were discussing in the TC meeting today that
led to my email, and exactly the issues you're wrestling with here. I think
if you reread my email in the context of that draft refactoring, the result
should be very much in line with what you're proposing for post 1.2: a
rigorous refactoring of the spec, with the core unspecialized markup support
being required and all specializations being optional (aside from default
inherited support).

Michael Priestley
Lead IBM DITA Architect 
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25

"Eliot Kimber" <ekimber@reallysi.com>

10/02/2007 04:09 PM

To	"Don Day" <dond@us.ibm.com>
cc	dita@lists.oasis-open.org, Michael Priestley/Toronto/IBM@IBMCA
Subject	RE: [dita] Specialization support: a core philosophical issue

By "separate specification" I mean a document
separate from what we mean by DITA 1.x [what we might call "the core
DITA specification"] that is a physically and legally separate standard
that normatively depends on the core DITA spec but is not itself part of
core DITA.  If the TC as chartered is only allowed to produce a single
specification (e.g. "DITA") and that means that the output of
various subcommittees is, by definition, part of core DITA, then I think
I am suggesting that those groups should be separate TCs in their own right.
If our charter allows the subcommittees to produce independent specs then
there's no problem--they can do their work, taking advantage of any real
or perceived added value being under the TC provides, but not require the
core DITA spec to include that work as part of the core feature set.

If the first case holds then I think we become faced with a situation where
we have to first define a proper conformance clause and then use that clause
to say that specializations X, Y, and Z are optional and what optional
means. Without that optionality then you end up forcing most implementers
to be nonconforming simply because few will be willing or able to implement
everything in the spec. It's easier to simply make the optional stuff separate
specs and make everything in the core DITA spec required by definition.

I think that DITA has to become a "family of standards" that
together represent a body of technology from which you can choose those
things you need, based on an invariant, required, core.

There is already confusion in the community about what "DITA"
is and isn't. There needs to be very crisp demarcation between those things
that are core to DITA as a technology and those things that are applications
of that technology. I don't think we do that well enough today.

I think there is a well-intentioned desire, both by users and by the DITA
developers, to include in the core spec everything that is useful to a
reasonable majority of the DITA community, thus the inclusion of bookmap
and glossentry in DITA 1.1. However well intentioned, that approach cannot
be sustained as the scope of application of DITA increases over time, which
it certainly will.

From a spec development standpoint, one could argue that bookmap and glossentry
would have been better defined as separate specifications in their own
right since neither is defining any core functionality for the DITA technology.
But it was clearly an appropriate *marketing* decision to include them
because such a large majority of the current and potential DITA audience
needs them.

But where does it stop? At some point you have to draw a line and say "everything
after this is a separate spec" and not part of core DITA. I'm suggesting
that line be drawn between 1.1 and 1.2, except for the small obvious specializations
we accepted or are likely to accept (e.g., mapref, text, etc.). 

That is, whatever is developed by the instructional design or machine industry
subcommittees, regardless of its value or scope of applicability, is, by
definition, not part of core DITA. Nor would be anything more general,
like glossentry, that the TC identified as being generally applicable.

As you point out there may be significant additional value in having a
particular specialization be developed under the DITA TC, such as the things
you outline. As an interested party I am of course more likely to *participate*
in the development of a specification if the governing body does things
to add value and instill confidence (such as protect patents or provide
supporting infrastructure or whatever). But that doesn't really change
how a given specialization will be accepted in the marketplace. What matters
to people is whether or not its supported by the tools they use. Being
or not being a standard rarely drives either vendor implementation or user
acceptance. Just saying.

I tend to be a deconstructionist when it comes to specs, just as I prefer
layered architectures for implementation. I'd personally prefer for the
DITA technology to be defined as a set of layered specs, one building on
the next, but making it clear what's core technology (map/topicref) and
what is specialization (map/topicref mapgroup/topichead). Of course, that
approach always raises the problem of how to define clearly a combination
of features that represent a unit of required or optional support for determining
conformance or compliance of applications and implementations. Recognizing
that I accept that the 1.1 set of features is probably about as a good
a compromise between precision (clear layering) and convenience (one monolithic
spec with no optional features) that we can have, I will not push for this
sort of deconstructing of the spec, but I think it's useful for us to recognize
that DITA as a technology does have inherent layers that are worth at least
acknowledging even if they're not legally distinguishable units of conformance
or distinct specs.

Cheers,

E.
----
W. Eliot Kimber
Senior Solutions Architect
Really Strategies, Inc.
512 554 9368


> -----Original Message-----
> From: Don Day [mailto:dond@us.ibm.com]
> Sent: Tuesday, October 02, 2007 2:07 PM
> To: Eliot Kimber
> Cc: dita@lists.oasis-open.org; Michael Priestley
> Subject: RE: [dita] Specialization support: a core philosophical issue
> 
> When you say "separate specification," Eliot, do you mean
a new TC
> activity, or formal endorsement by the DITA TC into the overall DITA
> standard?
> 
> I don't think we want to encourage the separate TC route for new
> Specializations (for reasons of expense, conflict of time among
> cross-attending members, confusion of leadership, and more).
> 
> Likewise, I don't think we want to devalue the SubCommittee's products
> because we think their efforts have no more value than specializations
> developed externally. They've paid for OASIS membership in order to
> develop
> their industry specializations within the authority and process of
> OASIS,
> and our process should continue to preserve that justification for
> their
> participation.
> 
> Our charter requires us to carefully consider admitting additional
core
> infotypes into the scope of work, and also to define a process to
> recognize
> additional specializations. Those subcommittees created by Resolution
> of
> the TC represent focused activities of special value to the TC, and
our
> TC
> should continue to recognize those industry-opening opportunities.
On
> the
> other hand, our charter also allows us to develop a process to
> recognize
> externally designed specializations. One big consideration here is
> Intellectual Property--OASIS owns the ideas developed within the
> SubCommittees, and presumeably those participating companies did a
> great
> deal of Due Diligence to ensure that there would be compensating value
> in
> the SC activity for that IP consignment. However good and useful
> externally-developed specializations may be, these do NOT have to
> submit
> their IP to OASIS, therefore we cannot brand or certify those products
> in
> the same way.
> 
> Using some possible language for the solution I see, I suggest that
we
> consider a tiered approach that retains the current value for the"
> Approved
> Specializations of the Core Specifications" of existing and future
> OASIS
> SubCommittees, yet allows designating useful implementations as
> "Recognized
> Specializations (or something less than Approved) of the Core
> Specifications."
> 
> Regards,
> --
> Don Day
> Chair, OASIS DITA Technical Committee
> Chair, IBM DITA Architects Board
> Email: dond@us.ibm.com
> 11501 Burnet Rd. MS9033E015, Austin TX 78758
> Phone: +1 512-244-2868 (home office)
> 
> "Where is the wisdom we have lost in knowledge?
>  Where is the knowledge we have lost in information?"
>    --T.S. Eliot
> 
> 
> 
>              "Eliot Kimber"
>              <ekimber@reallysi
>              .com>
> To
>                    
                   "Michael
Priestley"
>              10/02/2007 12:02  
       <mpriestl@ca.ibm.com>,
>              PM      
                 dita@lists.oasis-open.org
> 
> cc
> 
> 
> Subject
>                    
                   RE:
[dita] Specialization
> support:
>                    
                   a
core philosophical issue
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I generally agree with Michael’s analysis. The only thing I would
draw
> attention to is:
>   “specifications for standardized specializations” as “part
of the
> standard”
> We need to clearly define what “the standard” is in this context.
Do we
> mean DITA 1.2 as published, which presumes it includes a number
> specializations in addition to the core base types, or do we mean
any
> output of any subcommittee of the DITA TC?
> In general I think that the core DITA spec should only include the
core
> types as represented by DITA 1.1 (including bookmap and glossentry)
and
> that anything else should be published as a separate specification
so
> that
> it is clear what is core DITA and what is a separate, but standard,
> specification.
> The language around standard specializations also implies that they
are
> privileged but it doesn’t distinguish privilege simply because of
being
> standardized (by any body, not just the DITA TC) or because of being
> produced by the DITA TC. I would argue that there’s no particular
> useful
> distinction between a specialization module produced by a DITA TC
> subcommittee and one produced by any other recognized standards body:
> they
> both have to conform to the same rules and can be equally well
> validated
> against them (to the degree that the DITA rules are validatable),
> unless
> the DITA TC is guaranteeing that the subcommittee specs have been
> somehow
> vetted in advance of publication to ensure their correctness of
> implementation with regard to the base DITA spec. [Note that since
the
> current DITA spec does not have a conformance clause there’s really
no
> legalistic basis for saying that a given application is or isn’t
valid,
> even if we can determine that it is not valid technically.]
> From an implementation and use standpoint, having a given
> specialization
> module be standardized or not doesn’t really change anything: if
the
> module
> is valuable it will be used and implemented, if it’s not it won’t
be,
> regardless of its status as a standard. Being standardized doesn’t
> guarantee long-term maintenance or acceptance.
> I just want to make sure we’re clear as a committee about what we
are
> standardizing as distinct from what others might standardize.
> (And in case it’s not clear from the above, the current DITA spec
could
> be
> usefully broken into a truly core spec that only defines map and topic,
> with all of the other specializations of map and topic moved to one
or
> more
> additional specs—however, I’m not suggesting we do that for DITA
1.2,
> but
> doing it would make it much clearer that there’s nothing stopping
> another
> community for whom concept/task/ref isn’t useful from standardizing
> purely
> from topic and map.)
> Cheers,
> E.
> ----
> W. Eliot Kimber
> Senior Solutions Architect
> Really Strategies, Inc.
> 512 554 9368
> 
> From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
> Sent: Tuesday, October 02, 2007 11:15 AM
> To: dita@lists.oasis-open.org
> Subject: [dita] Specialization support: a core philosophical issue
> 
> 
> Per today's TC meeting, summing up my thoughts on required support
for
> the
> core spec (new minimal architectural spec plus core language spec)
vs
> for
> specialization specs (new separate docs for tech content, machine
> industries, etc.) vs for user specializations.
> 
> Core spec:
> - all DITA implementers need to support the core specification and
> provide
> its documented behaviors as defaults
> - we need at least three documented users for the core spec, per OASIS
> requirements
> 
> Standardized specializations:
> - some DITA implementers may also choose to support the extended
> specifications for standardized specializations and provide their
> documented behaviors as defaults, including cases where the specialized
> behaviors override the core defaults
> - we need at least three documented users for each standardized
> specialization, or it shouldn't be considered "baked" enough
to become
> part
> of the standard
> 
> User specializations outside the standard:
> - where a particular user or community creates additional
> specializations
> beyond those in the standard, they can expect default support based
on
> inheritance (from either the core, or from a standardized
> specialization if
> appropriate)
> - but if they want behaviors that override what they get by default,
> they
> will need to provide those overrides themselves
> - this is pretty much the same as if the user went with a vendor that
> didn't support the standardized specialization they needed (ie they'll
> get
> inherited behavior, but not specialized behavior, unless they develop
> it or
> someone develops it for them)
> 
> Sum:
> - everyone needs to support the core;
> - specialized support (beyond core defaults) for the specialized parts
> of
> the spec are optional but encouraged, and should represent an
> established
> user community;
> - specialized support (beyond core defaults or standard specialization
> defaults) for non-standardized user specializations are up to the
user
> or
> their partners to provide
> 
> Philosophical point:
> - specialization doesn't eliminate differences between markup languages
> (although it does reduce them), it provides a framework for managing
> those
> differences
> 
> Michael Priestley
> Lead IBM DITA Architect
> mpriestl@ca.ibm.com
> http://dita.xml.org/blog/25