OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dita] Issue 12055 Map referencing behaviors


Hi Jeff,

I don't want to put words in Michael's mouth, I'll give my own take on
this.

The toolkit has several overrides for specializations, although I think
that probably covers under a third of them. Offhand, I do not remember if
any of these are done to meet definitions in the spec, although I would
rather expect not. Also, I'd agree that the spec does not define a standard
method to share processing behaviors - it just defines how the class
attribute can and should be used to handle specialized processing.

That said -- there are many cases where a user defining a specialized
element reasonably expects to be able to get processing that does not match
the default fallback. I've seen several cases where specializations are
created in order to provide standard headers, text formatting or both. The
DITA spec does not forbid this, and does not provide a way to share those
modified behaviors among implementations. That is, there is no way for me
to define a specialized table such that all processors know that the first
column should have a (locale specific) default heading, although this is
not an uncommon thing to want.

I think that the proposal I originally submitted just goes much further
than the rest of the spec in pointing out that users may want a behavior
from their specialization that does not match the element from which
they've specialized. My own feeling is that this is not something new - it
has always been the case that a behavior might change due to
specialization. I probably just gave more details about it because, at the
time of writing, I had already seen several examples of that in practice.

In terms of encoding the behaviors in the DTD or Schema - I do not think
that the behaviors are simple enough to encode. A lot of the examples I've
seen come from Erik Hennum, so perhaps he can provide use cases here, but
an attribute that lists element names seems too simple. There is more than
one possible behavior that can be overridden for a map reference, so a
simple inherit/notinherit value probably won't cover many of the use cases.
I'm going to rely on Erik to provide those more complex examples.

To summarize, I think that it is normal for a specialized element to desire
processing that differs from its ancestor. Perhaps the proposal 12055 as
submitted went overboard in anticipating behaviors, and implying that
processors had to be ready to deal with them. Would it be better to simply
define the defaults, and state that as with any specialization, these
behaviors may change, but that achieving such changes are up to
implementation specific solutions?

Thanks for the discussion -

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit
(507) 253-8787, T/L 553-8787 (Good Monday & Thursday)


                                                                           
             "Ogden, Jeff"                                                 
             <jogden@ptc.com>                                              
                                                                        To 
             09/10/2007 02:57          "Michael Priestley"                 
             PM                        <mpriestl@ca.ibm.com>               
                                                                        cc 
                                       <dita@lists.oasis-open.org>,        
                                       "Grosso, Paul" <pgrosso@ptc.com>    
                                                                   Subject 
                                       RE: [dita] Issue 12055 Map          
                                       referencing behaviors               
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




OK, but for those cases where “the DITA Open Toolkit provides specialized
behaviors for about a third of the specialized elements in the DITA spec”
do the specialized behaviors provided override something that is required
in the DITA standard or do they override the processing for the base
element as implemented by the DITA Open Toolkit?

I see the “Specialization in processing” section of the DITA specification
as a collection of good practices for writing XSLT or CSS stylesheets for
use with DITA.  I don’t think it defines a standard method of sharing
processing behaviors unless the sharing is being done using the same
processing system such as the DITA Open Toolkit.

The DITA Open Toolkit, like all output processing systems, implements
portions of the DITA standard as well as other things that have not been
standardized and very often we do not want to standardize.  I guess a
question we may need to answer is, Are the behaviors being defined in Issue
12055 ones that we want to include in the DITA Standard or are they ones
that we want left open for customization?  And if we include them in the
DITA Standard, how much force do we want to give them?  Are they
requirements? Are they recommendations? Are they examples?

Michael, do you see any harm in providing additional information in the DTD
or schema as I have been suggesting (my option #3)?

    -Jeff


From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Monday, September 10, 2007 3:17 PM
To: Ogden, Jeff
Cc: dita@lists.oasis-open.org; Grosso, Paul
Subject: RE: [dita] Issue 12055 Map referencing behaviors


Re:

>The reason I am uncomfortable with this is that it requires that someone
who wants to define a new specialization that requires exceptions provide
both the specialized elements and behavior.  We have a standard way to
provide the specialized elements. We do not have a standard way to provide
the specialized behavior.

Actually we do - see the architectural spec section "Specialization in
processing".

>Without a standard way to provide the specialized behavior, someone will
need to reimplement the specialized behavior for different output
processing implementations. That will be extra work and seems likely to
result in different results as documents are moved from site to site and
implementation to implementation. We should avoid that if we can.

It's within the scope of normal DITA specialization to create a new
specialized element that has specialized processing. Some of the critics of
specialization have claimed that's the norm, which it's not, but it's not
the exception either. As one example, I believe the DITA Open Toolkit
provides specialized behaviors for about a third of the specialized
elements in the DITA spec. I believe most DITA users that are specializing
DITA are also providing specialized processing for at least some of their
new elements.

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



                                                                           
 "Ogden, Jeff"                                                             
 <jogden@ptc.com>                                                          
                                                                           
                                                                        To 
 09/10/2007 03:05 PM             Michael Priestley/Toronto/IBM@IBMCA,      
                                 "Grosso, Paul" <pgrosso@ptc.com>          
                                                                        cc 
                                 <dita@lists.oasis-open.org>               
                                                                   Subject 
                                 RE: [dita] Issue 12055 Map referencing    
                                 behaviors                                 
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





My own thought here is that we have three options:

1.        Define standard behavior that applies to all cases, no
exceptions.

2.        Say that the behavior is implementation dependent, possibly
giving an example of a desired behavior that may be implemented.

3.        Provide a standard behavior and a way to designate exceptions to
that standard behavior.

For this particular case I don’t think #3 would be too hard and so that
would seem to be a good way to go.

I am uncomfortable with the option that is being proposed which I take as
defining standard behavior, but allowing exceptions.  The reason I am
uncomfortable with this is that it requires that someone who wants to
define a new specialization that requires exceptions provide both the
specialized elements and behavior.  We have a standard way to provide the
specialized elements. We do not have a standard way to provide the
specialized behavior. Without a standard way to provide the specialized
behavior, someone will need to reimplement the specialized behavior for
different output processing implementations. That will be extra work and
seems likely to result in different results as documents are moved from
site to site and implementation to implementation. We should avoid that if
we can.

I could live with option #1 (no exceptions).  That puts the burden on the
author to use the “right” map elements when the behavior they want isn’t
the standard behavior.

I could live with option #2 (no standard).  That is what we do for most
output processing today.

And as I said, I think option #3 is the best approach.  I think all we need
is either:

a)       a new attribute similar to domain on the root element of a map
that accepts  a space separated list of topicref specializations whose
behavior should not be overridden when they are referenced using a
different element from a higher level map, or

b)       a new attribute similar to class on topicref and topicref
specializations that indicates that this element’s behavior should not be
overridden when referenced from a higher level map.

In either case, like domain or class, the new attribute would usually
appear with its default value in a DTD or schema and not in the instance.

And, if we want to, rather than using a simple list or a single attribute
value, we might define a keyword or grouping syntax for the values so that
we could use the same attributes for other similar purposes in the future
should the need arise. Some possible approaches:

            Simple list on the root element:  norefoverride=”element1
element2 … elementn”
            Single valued attribute on the topicref element or
specialization:  refoverride=”no”
Grouping syntax on the root element:
           processing_exceptions=”norefoverride(element1 element2 …
elementn) somenewoption(somenewvalues)”
            Keyword list on any element:
processing_exceptions=”norefoverride somenewoption someothernewoption”

  -Jeff




From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Monday, September 10, 2007 12:06 PM
To: Grosso, Paul
Cc: dita@lists.oasis-open.org
Subject: RE: [dita] Issue 12055 Map referencing behaviors


I think the wording needs some clarification - I don't think what you're
reacting to is actually Robert's intent.

Robert, I'm going to try to paraphrase here:

If someone specializes a map to create a new map-referencing element, they
can define specialized processing for that element if they want.
Applications that are not customized or extended to provide special
handling for the specialized element should instead treat the specialized
element according to its ancestry (ie, according to whatever behavior is
provided in the spec for that element).

I don't think Robert is saying more than the above, and that's true of all
specializations. He's just pointing out that the behavior defined in the
spec can be overridden by someone providing specialized elements and
behavior.

Why is it worth calling out at all then? I think because there are some
behaviors that we consider architectural (eg conref, the class
attribute...) that need to be consistent across specializations because
they are designed to provide interoperability across specializations; there
are other behaviors that are implementation-specific, in which the
behaviors we provide are defaults that can be overridden, rather than
normative for the class of all possible DITA document types. I think
map-referencing behaviors fall in the latter class, and that's what Robert
is trying to say.

Robert, correct me if I'm wrong. Paul, does that re-interpretation address
your concerns?

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


                                                                           
 "Grosso, Paul"                                                            
 <pgrosso@ptc.com>                                                         
                                                                           
                                                                           
 09/10/2007 11:27 AM                                                       
                                                                           
                                                                        To 
                                           <dita@lists.oasis-open.org>     
                                                                        cc 
                                                                           
                                                                   Subject 
                                           RE: [dita] Issue 12055 Map      
                                           referencing behaviors           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           








Robert,

If I understand correctly, you are suggesting that different
specializations can do different things based only on some
writeup in the standard.

Jeff and I have said that is the one choice we find unacceptable.
Either there needs to be some machine-readable way to determine
behavior (e.g., encode it in the DTD/XSDs), or all behavior must
be consistent.  Having to hardwire potentially conflictly behavior
into an implementation for each specialization is not a good option.

Jeff and I will try to discuss this some more before tomorrow's
meeting, but I wanted to respond as soon as possible.

paul

> -----Original Message-----
> From: Robert D Anderson [mailto:robander@us.ibm.com]
> Sent: Monday, 2007 September 10 8:29
> To: dita@lists.oasis-open.org
> Subject: Re: [dita] Issue 12055 Map referencing behaviors
>
> Hi everybody,
>
> There is still no response to this one, so my plan for
> tomorrow's meeting
> is to keep to the original proposal. The specification should describe
> default behaviors for references from one map to another map,
> but allow
> that specializations may define alternate behaviors as appropriate.
> Compliant DITA processors should be expected to follow any alternate
> behaviors for OASIS approved elements, because those behaviors must be
> described as part of the specification. However, there is no
> mechanism for
> processors to automatically determine the non-default
> behaviors for other
> specializations.
>
> I would be happy to have a way to define non-default behaviors for map
> references. However, I am not sure how to come up with one
> that is simple
> enough to use, so it is not a part of this proposal.
>
> Thanks,
>
> Robert D Anderson
> IBM Authoring Tools Development
> Chief Architect, DITA Open Toolkit
> (507) 253-8787, T/L 553-8787 (Good Monday & Thursday)
>
> Robert D Anderson/Rochester/IBM@IBMUS wrote on 09/05/2007 04:28:03 PM:
>
> > In an attempt to draw out more responses on this one ...
> >
> > The issue under discussion is how to define differences in
> behaviors. To
> > make it easier, I will give a specific example.
> >
> > We have a chapter element defined in bookmap. When this
> points to a map,
> it
> > casts the referenced material in the role of a chapter, or
> a sequence of
> > chapters if there are multiple top-level elements. Attributes and
> metadata
> > will cascade to the referenced 'chapters'.
> >
> > Within IBM we have another specialization, <topicsetref>.
> This is used to
> > point to commonly reused branches on a map. The behavior
> here differs -
> the
> > referenced material clearly is not cast into the role of a
> topicsetref.
> > Additionally, the topicsetref element defaults @type to
> 'topicset', which
> > indicates the type of the referenced target but should not
> be passed to
> the
> > targets. So, the map referencing behavior differs between
> chapter and
> > topicsetref.
> >
> > Because map is the most general DITA collection structure, it should
> allow
> > appropriate processing based on the type of the collection
> and the type
> of
> > the collected content objects.  That is, standard DITA map
> processing
> > behaviors are defaults appropriate to default DITA topics but don't
> > preclude other processing behaviors.
> >
> > Options mentioned so far for defining this are:
> > 1) We specializers must expect to override programs to get anything
> > different from the default.
> > 2) We define overridable behaviors; programs may try to
> make it easier to
> > supply overrides to implement alternate behaviors
> > 3) Any behavior that differs from the default must be
> encoded in the DTD
> or
> > Schema (using a new, to-be-defined notation)
> > 4) OASIS approved elements that differ from the default
> must define the
> > difference in the specification. Default support for these
> differences
> > should be expected in processors, but simple support for
> differences in
> > user-created specializations is not guaranteed
> >
> > My own preference is for #1, because a) I think that
> differences from the
> > default should be expected, and b) I think defining those
> behaviors in
> the
> > DTD or Schema will be prohibitively complex. I would also
> be happy with
> #2,
> > although I do not think we can come up with a full list of
> overrides,
> just
> > like we cannot come up with a full list of specializations.
> If somebody
> can
> > suggest a DTD or Schema notation that is expandable and
> simple enough to
> > use for any case that might come up, I would readily shift
> my allegiance
> to
> > #3.
> >
> > Thanks -
> >
> >
> > Robert D Anderson
> > IBM Authoring Tools Development
> > Chief Architect, DITA Open Toolkit
> > (507) 253-8787, T/L 553-8787 (Good Monday & Thursday)
> >
> > Robert D Anderson/Rochester/IBM@IBMUS wrote on 08/30/2007
> 04:56:00 PM:
> >
> > >
> > > This is in reference to the proposal posted here:
> > >
> >
> http://www.oasis-open.org/committees/download.php/24910/IssueN
> umber12055.html
>
> >
> > >
> > > As noted at Tuesday's meeting, there has been some
> discussion off the
> > list
> > > about this item, primarily related to default behaviors.
> This proposal
> > > states that the described behaviors (such as that for cascading
> metadata)
> > > may change in a given specialization. For example, in the general
> > topicref
> > > case and in most specializations, metadata specified within the
> > <topicref>
> > > applies to the referenced content. This means that a
> processor could
> > treat
> > > specified metadata as if it was specified in the target
> topicref's.
> > >
> > > In some cases, the topicref element may be specialized to provide
> meaning
> > > about the referencing context, rather than the target. In
> that case it
> > may
> > > be possible to set metadata that should not cascade to
> the targets, but
> > > should only be used to evaluate the reference itself.
> > >
> > > As I understand it, the open question is - how should
> such overrides of
> > the
> > > default behavior be defined? If they are not defined
> within the DTD or
> > > Schema, how can a tool anticipate the desired behavior?
> If they are
> > defined
> > > within the DTD or Schema, how can that be done, in a manner that
> > > anticipates all of the overrides? If the changes are
> simply defined in
> > the
> > > element documentation, then tools will be unable to automatically
> > > understand how to treat the elements, and they will
> require overrides.
> > >
> > > Another, I believe less urgent, open question is about
> the terminology
> of
> > > cascading versus inheritance. It has been suggested that
> the behaviors
> > > described here, as well as in much of the map processing, is more
> > properly
> > > described as cascading rather than inheriting. The
> proposal here uses
> the
> > > term "cascade". When this goes into the specification, it
> will use the
> > same
> > > terminology as the spec, whether that ends up being
> cascade or inherit.
> > >
> > > Thanks -
> > >
> > > Robert D Anderson
> > > IBM Authoring Tools Development
> > > Chief Architect, DITA Open Toolkit
> > > (507) 253-8787, T/L 553-8787 (Good Monday & Thursday)
> > >
> >
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]