You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Probably many DocBook users has still a XSLT 1.0 code base. When you want to migrate this code base to the new XSLT 3.0 stylesheets, people probably search for the respective parameter in the xslTNG documentation. In most cases, they won't find these parameters as they have different names now.
This makes it harder to migrate to the new stylesheets.
Possible solution
To ease the migration from old to new, could we document the correct mapping from old to new? Certainly, there are not always a one to one match. Or parameters don't have an equivalent new parameters. Or are split between two now. There are probably many ways.
I could think of these solutions which could improve this migration task:
Document the mapping from old -> new in a separate section.
It doesn't have to be much, maybe a table would be sufficient. Perhaps we could also document when there is no equivalent new parameter for the old one.
Document the old name inside the parameter description.
Not sure what's the best approach here, but I like point (1) because that would be probably the place where a stylesheet developer would search first, wouldn't they?
I think, this would also align well with the migration documentation that I've created in #212.
Problem
Probably many DocBook users has still a XSLT 1.0 code base. When you want to migrate this code base to the new XSLT 3.0 stylesheets, people probably search for the respective parameter in the xslTNG documentation. In most cases, they won't find these parameters as they have different names now.
This makes it harder to migrate to the new stylesheets.
Possible solution
To ease the migration from old to new, could we document the correct mapping from old to new? Certainly, there are not always a one to one match. Or parameters don't have an equivalent new parameters. Or are split between two now. There are probably many ways.
I could think of these solutions which could improve this migration task:
It doesn't have to be much, maybe a table would be sufficient. Perhaps we could also document when there is no equivalent new parameter for the old one.
Not sure what's the best approach here, but I like point (1) because that would be probably the place where a stylesheet developer would search first, wouldn't they?
I think, this would also align well with the migration documentation that I've created in #212.
Related
See #212
The text was updated successfully, but these errors were encountered: