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


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-tc message

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

Subject: Re: assembly schema update

"Bob Stayton" <bobs@sagehill.net> writes:
> I've gone through the DocBook TC minutes and it looks like the assembly schema has not
> been updated to reflect the latest changes the TC has approved.  The last version you
> posted was 5.1b6 on 16 January 2012, and that does not include the changes I've listed
> below.  Could you please update it so I can make sure the XSL stylesheets I'm working
> on match it?

Except for my question below, I think the attached schema implements
the changes. Please let me know if you think I got it wrong in some

> 1. Remove the "content" versions of module and resource. This goes back to the
> original design of putting all content in resource files that are referenced by
> resourceref.


> 2.  Remove bibliography, glossary, index, and toc elements from module and structure.
> Where you need to insert such an element, use module with a renderas attribute. For
> the case where you need an empty index element as a placeholder for a generated index,
> then use an empty module: <module renderas="index"/>. This approach avoids including
> special elements in the module content model.


> 3. Replace info with assemblyinfo to make it clear that this metadata is only about
> the assembly elements themselves. It could have a different content model from info,
> since it would not carry any text to be rendered in the output, such as title,
> titleabbrev, etc.

Overtaken by events, I believe.

> 4.  Remove title, titleabbrev, and subtitle elements from module (see next item).


> 5. Keep the override element in module and structure. That would be the only place
> that text content would be allowed in an assembly, and would include title,
> titleabbrev, and subtitle elements among others. If someone uses this optional element
> and still needs translation, they can restrict the translation of the assembly file to
> the text elements inside any override elements.


> 6. For those who don't want any content in their assembly but need to override the
> info for a given resource, allow override to have a resourceref attribute that points
> to a resource that references a file containing the info overrides. One could even
> have several overrides if they are conditional and only one is selected.

This is a resourceref attribute on <merge> then?

> 7. And the change I proposed earlier: add resourceref to structure to allow it to
> reference a resource for the root element and front matter. Keeping structure as a
> separate element from module for the root element gives us the flexibility for it to
> have different attributes or content for that critical location.

Done. Not sure what the extra-grammatical constraints on resourceref should be,
but the attribute exists now.

> These following changes were approved at the 18 January 2012 meeting:
> 1.  Use a single element name <info> for metadata about assembly elements.
> 2.  Replace <override> with <merge>


Attachment: assembly.rnc
Description: Binary data

                                        Be seeing you,

Norman Walsh <ndw@nwalsh.com> | Great success is commoner than real
http://nwalsh.com/            | abilities.-- Vauvenargues

Attachment: pgpNt4fnFAbd5.pgp
Description: PGP signature

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