OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

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

Subject: Re: [docbook] Prosposed changes to Programlisting

On Fri 2004-02-20 Elliotte Rusty Harold wrote:
> I do not find the idea of a "filecontent" element to be useful. It
> feels too generic.

It's less generic than literallayout, and conveys semantics.

> For instance, not all files contain content that should be processed
> as literallayout.

An attribute could be added allowing you to specify this, or xml:space
could perhaps be used.

> Hell, not all files can even be included in DocBook. I've recently
> been working with the XML conformance test suites and having a hell
> of a time with files that are deliberately broken by containing XML
> illegal characters such as null.

I fail to see how those two arguments counter the general usefulness
of an element "filecontent" (it's OK if it's not useful for everyone,
and does not fit in all scenarios: which XML element could possibly
make illegal characters be legal?).

programlisting and literallayout are not always appropriate:

Let's say I want to include a file snippet. It's not a program, so
programlisting is out. literallayout is an element which is
exclusively concerned with layout, which makes it a poor choice IMHO.

So we could go with something looking like one of those:

  <filefragment xml:space="preserve">whitespace (WS) should probably
  be preserved by default[...]

  <filelisting layout="flow">WS/layout is not preserved now [...]

  <documentfragment syntax="xml">[...]



Vim users, don't forget to

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