Re: [docstandards-interop-discuss] Clarifications / Scope of the intended work?

[marbux <marbux@gmail.com>]

On 4/11/07, Dave Pawson <dave.pawson@gmail.com> wrote:
> On 10/04/07, marbux <marbux@gmail.com> wrote:
>
> > For example, the Apache Cocoon development team has already developed
> > a XML-based scripting language ("sitemap" in Cocoon parlance")
>
>
>
> > I haven't checked in to see what happened with it, but there was also
> > an OASIS proposal roughly a year ago to develop a similar language for
> > scripting  transformations
>
>
>
> For what purpose?
>
Basically an interchange format for conversions to Windows Help (CHM)
format. The discussion was being pushed by a company that markets a
converter application that can convert documentation files produced in
a variety of formats to CHM. They wanted an intermediate XML language
for mapping the other formats to. So, e.g., documentation might be
written in Dreamweaver or Word or Docbook, etc., but all map to CHM.
(This is from my somewhat dated memory.)

> > I like the idea of raising the abstraction level of transformation,
> > aggregation, etc.  methods to a meta-level hub language, particularly
> > if it can be implemented in a user-friendly way.
>
> Is this an 'Esperanto'  based solution? From format A into Esperanto,
> then Esperanto out to format B?
>

No, at least the way I understand what's being proposed. If you
haven't done so, it might help to take a look at the slides Mike
linked earlier.
<http://flatironssolutions.com/Downloads/DITA2007West.pdf>. I'll
probably describe it more poorly, but it seems like the proposal is
for a meta-language to be used for scripting the extraction,
transformation, aggregation, and serialization of data from a variety
of documentation formats to a variety of documentation formats. So
basically an XML scripting language to automate such steps. So rather
than Esperanto, something more like the "sitemap" XML language used by
the Apache Cocoon project, something closer to XSL:FO than Esperanto,
but abstracted another layer so that processing of a variety of
transformation languages could be scripted using the same scripting
meta-language. (That's probably clear as mud and may be wrong to boot,
so take it with a grain of salt.)

>
>
>
>
> > On the pageless/paper document distinction, there should be provision,
> > I think, for preserving paper document metadata from the source data,
>
>
> I disagree, but would like to hear the rationale, including examples
> where the sender and recipients 'pages' are totally different, and how
> mapping might address this.
>
>
As I understand it we're not discussing a sender-recipient
interaction, at least in a human sender-recipient sense. We're more
concerned with automated extraction of data, its transformation, its
aggregation, and its serialization.

Let's assume our implementing app was used in the legal field and part
of what was being extracted had line numbering and the text being
extracted had references to line numbers. You'd want the implementing
app to extract the line numbers and keep them the same once the data
the data is transformed, aggregated with other data, and serialized to
the format need by the app that will make the presentation. Loop the
same concept for list item numbers and page numbers.

> >
> > Granted, I have about 10 minutes of total time spent studying the
> > tutorial, but this one near the top caught my eye. I think it
> > essential that the proposal recognize that we live in a relevant time
> > of transition.
>
> My view is that this is not in scope for this TC.
>

Perhaps. I could easily have got 90 per cent of what's gone by on this
list wrong. As I said, I'm not a code warrior. But if I am
understanding what's being proposed, then unique traits of a paper
format document being extracted might well need to be preserved in
some fashion.

> > I also think it absolutely essential that accessibility validation be
> > part of the foundation being constructed for this proposal.
>
> Accessibility of what please? The source format, the 'Esperanto' solution
> (as an intermediary language) or the target format?
>

All three. Say a source document includes VoiceXML document navigation
code and you want the output data to include Voice XML or some other
document navigation language. Then you need to preserve and transform
the relevant accessibility features of the document and have it
translated into some format with useful accessibility navigation in
the output. You might take a look at HawHaw, a PHP web app for
producing web pages for full screen and mobile devices that can
transform on the fly a variety of document navigation languages
including VoiceXML using an XML intermediary language for scripting
the process. <http://www.hawhaw.de/>. Its intermediary XML language is
also analogous to what's being discussed here, I think.

>
> But
> > extraction and aggregation of data from a variety of formats presents
> > some obvious problems for producing accessible documents as output
> > from such a hub. So I'd say call in the accessibility experts very
> > early on.
>
> No expert, but I've been working with WAI for 10 years.

Great. I recall that you did some work with ODF transformation for the
Daisy app. It will be wonderful if you can at least monitor what
happens here and chime in when you think accessibility issues might be
involved. I'm still fairly superficial in that area, but am concerned
about it because of the all too general neglect of accessibility
issues in software development. Plus I spent a couple of years in
hospitals after I got back from Viet Nam with a lot of other guys who
had severe and permanent disabilities. There but for the Grace of God
go I; but I was lucky enough to recover much more completely. But I
can't in good conscience go along with the software industry's too
generalized indifference to such people's computing needs.

Got to fly; I'm indentured to my daughter tonight, installing Linux on
her computer. I'd be interested in feedback on whether I'm coming
closer to an understanding of the suggested work.

Best regards,

Marbux