First, I need to wipe away the puddle of drool on my desk. Those features would be glorious to have.
The driving force in wanting to increase the use of xpath_eval in many different Oxygen customizations is that we're planning on moving from Ant/Java style properties files for build options and metadata to using the Ant [https://ant.apache.org/manual/Tasks/xmlproperty.html
]XMLProperty[/url] Task so that we can use Oxygen's xpath_eval function to retrieve any property that other tools may define, query, and update in a DocSet's repo.
We also want to be able to provide a multi-layered inheritance of properties at many levels such as company, business group, product family, product, platform, and document, and allow for each property to support either a top-wins or closest-wins inheritance/override strategy independently.
The initial use case is to move our current set of External Tools that we now must duplicate and update in every product's Oxygen project files. Those external tools would be much easier to update and distribute if they were ported to custom toolbars or menus in our framework. One category of such tools is to launch pertinent web pages on various internal servers that pertain to the DocSet, such as the:
- Jenkins page that contains the jobs for the project
- Gerrit or Gitlab server pages for the project's repo
- Artifactory server pages where Jenkins deposits the rendered docs so R&D can pick them up from their build toolchain
- Jira JQL query to view all documentation tickets for the product
It should make it easier for the writer to use Oxygen as their base application without having to switch to other tools to keep browser bookmarks for any related web apps they use.
Although most writers follow our recommended conventions for naming and locating related resources, we can't count on the fact that we can take the repo name, branch name, productID, or other metadata and construct the proper URL. So we need the user to be able to override these if necessary. Oxygen's Custom Editor variables would work for Oxygen, but not as easily with other parts of our build pipeline in their Oxygen project files. (I know that a project file is itself and XML file, but I don't think it would be best to make it the primary source of such metadata.) The required set of Editor variables could however access the XML properties using xpath_eval. Any Oxygen customization with xpath_eval support would be able to leverage the same properties. Other XML tools could use the same files for their purposes. We could run transforms and all sorts of other operations and queries on them if necessary. We may eventually create a simple Author mode for such files to make it easier on the writers... unless someone else has already created an addon for Oxygen to support XMLProperties.
I just used XMLStarlet for the first time to get at XML content from Bash scripts, and having properties in XML files would give our scripts access to the same XMLProperty set.
Do you see any flaw in this approach or other opportunities?