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: Possible schema issues related to db4-upgrade.xsl

Alexey Neyman identified some concerns with db4-upgrade.xsl, and has provided some very useful updates to the program. Since I also use the program, I volunteered to test and extend his changes and see how close we can get to a really clean 4.x to 5.x conversion. The testing was done with the Sourceforge test cases, which are 4.x based.

In the process of doing that, I've run across some test cases that raise issues that might be of interest to the TC as we look at 5.1.

1) The 4.x content models for <glossterm> and <term> allow <cmdsynopsis> or <methodsynopsis> as child elements, but 5.0 does not. There are test cases for <glossterm><cmdsynopsis> and <term><methodsynopsis>  in Sourceforge, but I don't know if that was done because the test writer thought these were valid use cases, or just for completeness.

2) The <modespec> element was removed in 5.0, because the current processing model for <olink> has changed, and the element is no longer needed for the original purpose. However, there is a test case that uses <modespec> to contain text, which is then referenced in the endterm attribute in an <xref>. I.e., the contents of <modespec> are used to supply the link text for an <xref>. Looking at the current schema, I could not find an element that could easily substitute. <modespec> was convenient in this role because it is the only element I could find that is reliably not directly rendered. There are other elements that are usually not rendered, but I couldn't find one that is reliably not rendered.

3) In 4.x, we allowed <affiliation> as a direct child of <biblioentry>. In 5.0, we do not. Instead, <affiliation> has to be the child of a much more limited set of elements (author, collab, editor, org, othercredit, person). I think what was done in 5.0 makes sense, but again, since there are test cases that do this in 4.x, I raise the question as to whether this is a valid use case that we should consider.

In all three cases, I think the right choice was made for 5.0, but I want to bring the cases to the TC to make sure we agree. Also, since none of the cases has easily automated alternatives, any suggestions on how db4-upgrade.xsl might handle them would be welcome:).

Best Regards,
XML Press
XML for Technical Communicators

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