RE: [dita] bookmap specialization question

[Erik Hennum <ehennum@us.ibm.com>]

Hi, Bruce:

As it happens, that thought has a lot in common with an idea that John Hunt, I, and some others have been investigating. The basic idea is to style DITA content by example. That is, the designer creates a policy document that uses elements and outputclass attributes as selectors for content and specifies the properties for those selectors (rather like CSS but validated and not limited to that CSS selectors, CSS properties, or HTML output). John will be providing a snapshot of the current state of the investigation at the <XML 2006> Conference (on December 7th in Boston) and should be able to share that presentation with anyone who's interested.

To be usable, unfortunately, the approach depends on the contextual domains / constraints feature proposed for DITA 1.2 -- that allows the <data> specialization to control which element supports which style properties. (All the more spur to move forward?)


Hoping that's interesting,


Erik Hennum
ehennum@us.ibm.com

Bruce Esrig <esrig-ia@esrig.com>

Bruce Esrig <esrig-ia@esrig.com>

11/19/2006 12:27 AM

To	Erik Hennum/Oakland/IBM@IBMUS, "Amber Swope" <amber.swope@xmetal.com>
cc	<dita@lists.oasis-open.org>
Subject	RE: [dita] bookmap specialization question

It is tempting to relax our ideal (in order to limit the work of the DITA TC) of specifying only a source language and not directly supporting processing.

Would we contemplate offering formal support for a convenience mechanism that defines processing based on templates?

Rather than requiring customization of processing by programming, it would be more convenient if customizers could declare a pseudo-topic with its sources and have those sources pulled together to form actual output.

A desperately-needed prerequisite would be a templating language that supports some simple layout ideas (a contradiction in terms?). At its most primitive, this could be a hybrid of conref-like constructs and FO-like directives.

The advantage would be that there would be a place to go when the need to customize crystallizes, short of reaching in to the implementation.

Best wishes,

Bruce

At 06:48 PM 11/17/2006, Erik Hennum wrote:

Hi, Amber:

I would submit there's a big difference between the preface (which has a content flow composed of paragraphs, lists, and so on like any other topic) and the title and cover pages, which have values but have no real content flow. We want to be able to put any topic into the role of a preface, but if we used topics for the cover and title, we would certainly need to create topic specializations that allow only the specified data values.

I'd also submit that we realize some significant benefits by keeping the book information in one spot instead of splitting out book information into cover and title topics:
• Some information might be appear in both the cover and title (but we surely only want to maintain those values in one place).
• The processor should be free to choose which information to display as part of the cover and title. For instance, one layout might choose to display product version information on the cover page while another chooses to display it on the title page.
• The summary book information is easily processed by applications that are entirely indifferent to the layout of the book. For instance, a bibliography builder.

In passing, because the cover and title are generated from bookinfo, it's no accident that the information for a cover and title are already defined as elements.

If we can generate the cover and title as part of the output, what's gained by moving that information into topics? If the goal is to give more of a WYSIWYG experience, I don't think that can be achieved with cover and title topics. I would think that having a separate method for defining the cover and title layout for the book information and then rendering the book information in that shared layout would be much more effective (but perhaps a lot of effort for just two pages).


Hoping that's useful,


Erik Hennum
ehennum@us.ibm.com

"Amber Swope" <amber.swope@xmetal.com>

"Amber Swope" <amber.swope@xmetal.com>

11/17/2006 02:38 PM

To

Erik Hennum/Oakland/IBM@IBMUS

cc

<dita@lists.oasis-open.org>

Subject

RE: [dita] bookmap specialization question


Erik,

I agree that the layout of the cover is up to the process, but the fact is that many folks want a topic that is assigned the role of the cover. The same goes for the title page. And the interesting thing about both of these is that, I believe, most of the elements you would want to represent the information are already in the bookmap specialization. For example, the title, author, edition number, publisher, etc. are all in the bookmap specialization and would hazard that having the role without every possible piece of data is better than not having the role.

I guess I’m not understanding the difference between assigning a role to a topic to be a preface versus to be a title page.

Thanks, A


---


From: Erik Hennum [mailto:ehennum@us.ibm.com]
Sent: Friday, November 17, 2006 12:41 PM
To: Amber Swope
Cc: dita@lists.oasis-open.org
Subject: RE: [dita] bookmap specialization question

Hi, Amber:

In the preface case, the bookmap is assigning a role to a topic. Without knowing the topic's role, a process can't apply special treatment to the preface topic. Examples of that special treatment might be as trivial as outputting a "Preface" label on the page or as sophisticated as applying special weight to high-frequency words from the preface when generating a fulltext search index for a book.

For the cover of the book, bookmap certainly needs to capture all of the information that should appear on the cover. After that, however, the layout of the cover is up to the process (as part of the separation of presentation and content).


Hoping that clarifies,


Erik Hennum
ehennum@us.ibm.com

"Amber Swope" <amber.swope@xmetal.com>
"Amber Swope" <amber.swope@xmetal.com>

11/17/2006 11:43 AM

To

Erik Hennum/Oakland/IBM@IBMUS

cc

<dita@lists.oasis-open.org>

Subject

RE: [dita] bookmap specialization question




Thanks, Erik.

I guess I don’t understand that difference between specifying an element for generating a cover or preface v. a preface, which the bookmap specification does provide.

Thanks, A


---


From: Erik Hennum [mailto:ehennum@us.ibm.com]
Sent: Friday, November 17, 2006 11:05 AM
To: Amber Swope
Cc: dita@lists.oasis-open.org
Subject: Re: [dita] bookmap specialization question

Salutations, Amber:

I think the expectation is that the book information provides everything needed to generate cover and title pages and that, like all presentation, the specification of the layout of the cover pages should be separate from the content of the book.

A question is whether there might be easy ways for adopters to define that layout -- but that question could be investigated separately without slowing down the completion of bookmap.


Hoping that's interesting,


Erik Hennum
ehennum@us.ibm.com


"Amber Swope" <amber.swope@xmetal.com>

"Amber Swope" <amber.swope@xmetal.com>

11/17/2006 08:44 AM

To

<dita@lists.oasis-open.org>

cc

Subject

[dita] bookmap specialization question




Hi there,

In reviewing the bookmap specialization, I realized that it contains elements for many of the common pieces of a book, but is missing elements for cover and title page. Is there a reason for this? I expected there to be elements so that you can specify a <topicref> for these items. Is it too late to add them?

Thanks, A

Amber Swope
Principal Consultant
XMetaL, a JustSystems company

Cell: 503-347-3569
amber.swope@xmetal.com
www.xmetal.com