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] Containers for steps and other elements!?

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
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
        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".

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

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