RE: [dita] Containers for steps and other elements!?

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

Just a quick note that multiple selection
does cause problems for conref. For example, if I specialize <steps>
to <shortsteps> and only allow one <step> element as a child,
how do we prevent conreffing multiple <step> elements into that location?

I think France mentioned that you could
add another validation layer, but part of the attraction of conref to date
is that it is able to validate on its own based entirely on comparisons
of the architectural attributes (class and domains) in source and target.
Adding another validation layer will require additional thoughts on how
to pass that validation logic along with a document.

Michael Priestley
mpriestl@ca.ibm.com
Dept PRG IBM Canada  phone: 416-915-8262
Toronto Information Development

Don Day <dond@us.ibm.com> 09/27/2004 09:02 AM

To:        dita@lists.oasis-open.org         cc:                 Subject:        RE: [dita] Containers for steps and other elements!?

Paul Antonov <apg@syntext.com> wrote on 09/27/2004
06:49:16 AM:

> Handling start/end ID's and selecting nodeset from between may be
tricky
> with XSLT. 

And I further assert that it is not wise to rely on the literal sequence
of the selectable elements in the source. (I'm aware of one of the stylesheet
examples in Serna in which an unordered list can be presented in the author's
view as sorted, which makes the indication of start and end attributes
in the actual source unreliable.)

>    Another variant is to use tags in addition to conref:

This is a good idea, Paul.  My first impression is that your technique
looks a lot like a particular case of conditional processing in which the
condition for selection is encoded within the conrefing element, rather
than as a run-time parameter passed to the XSLT templates for matching.
 If so, couldn't we use one of the existing %select-atts; attributes
in place of the @tag attribute? Then, in place of @conref-tag on the conrefing
element, perhaps a more general mechanism would be @select="term"
or @skip="term" (hmm, and qualified by whatever select-att the
author chose: platform, product, audience, otherprops) to provide appropriate
filtering of elements in scope that have matching terms.

This proposal would add the @select and @skip attributes to the select-atts
(and ideally only to elements that use @conref, but DTD's won't allow this).
 I cannot see any way to use just the existing select-atts (conref
and id) to provide the qualified selection required of this new sense of
a "conditional conref".

Regards,
--
Don Day <dond@us.ibm.com>
Chair, OASIS DITA Technical Committee
IBM Lead DITA Architect
11501 Burnet Rd., MS 9037D018, Austin TX 78758
Ph. 512-838-8550 (T/L 678-8550)

"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot