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] Bookmap/XNAL repercussions

I was discussing that some with Erik Hennum -- my thought is that yes, I
think it would be backwards compatible, but it might depend on how that
item is designed. Somehow, users will be able to create a structural
specialization that requires or uses a domain element. I have not had any
input on that discussion, so I'm not sure how it will be done.

One way to make this backwards compatible would be to move XNAL to a
domain, but write the bookmap module so that it still requires that domain
element. Any specialization of bookmap would still have to have the XNAL
elements, but it would be available as a domain for any other topic type or
map type.

I'm not sure if that would work or not. My hope is yes, but if not, it
could remain a part of bookmap until 2.0. By keeping the current design in
the implementation, it would still be available anywhere else as a domain
once 1.2 comes out. That's why I was a bit wishy-washy in saying we could
move it in 1.2 or 2.0.

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

"Paul Prescod" <paul.prescod@xmetal.com> wrote on 06/20/2006 02:29:45 PM:

> Wouldn't moving XNAL into its own domain be backwards incompatible when
> we do it in DITA 1.2?
> > -----Original Message-----
> > From: Robert D Anderson [mailto:robander@us.ibm.com]
> > Sent: Tuesday, June 20, 2006 12:11 PM
> > To: dita@lists.oasis-open.org
> > Subject: [dita] Bookmap/XNAL repercussions
> >
> >
> > As I make the bookmap changes from today's meeting, I'm also
> > merging it with the other 1.1 prototype files that are
> > available. While doing that, the decision to make XNAL into a
> > domain has demonstrated some side effects.
> >
> > The XNAL domain adds one element, authorinformation, as a
> > specialization of <data>. The <data> design has it appearing
> > in many more locations than I had first understood, including
> > inside most other meta elements. This means that, among
> > others, the authorinformation element now shows up inside
> > elements like <source>, <category>, and <platform>.
> >
> > I've mentioned before that the XNAL domain will not be useful
> > in topic specializations until domain specialization is
> > enhanced, allowing you to limit where your new element shows
> > up. That enhancement has been talked about for DITA 1.2. I
> > thought that bookmap's constrained model worked around this
> > problem, but it is becoming clear that I was wrong. So,
> > primarily for usability reasons, I would propose the
> > following changes to
> > bookmap:
> >
> > 1. Do not include authorinformation as a domain. Instead,
> > include it directly in the bookmap as a child of bookmeta.
> > 2. Continue to define all of the XNAL elements in a separate
> > module. In DITA 1.2 or DITA 2.0, plan to move XNAL to a
> > domain. This will be easy because it is already maintained in
> > its own module.
> >
> > Are there any concerns with this proposal?
> >
> > Robert D Anderson
> > IBM Authoring Tools Development
> > Chief Architect, DITA Open Toolkit
> > (507) 253-8787, T/L 553-8787
> >
> >

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