mbakeranalecta
commented
10 years ago Hi George,
Actually, I am using this validation regularly. During major reorganizations, however, it sometimes takes a while to make all the changes involved to achieve the correct fix across all builds.
I have been trying to do a separate check in for each significant change I make, so that we have a clear record of what has been done. That does mean that some of my checkins do not pass all validation checks and do not build fully correct docs. I have also been pushing my work at the end of each day so that you can see what I have been working on. But I have not been trying to ensure that everything was valid before doing that push.
If you prefer, I can switch to a different approach for checkins and pushes. (Actually, I suspect this will be less of an issue once we finish with install, as the rest of the content does not have the platform-specific issues that complicate the organization of the install material.)
Alternatively, I can do major reorganizations in branches and only merge back to the dev branch when they validate and build correctly.
Let me know what you would prefer.
From: George Bina [mailto:notifications@github.com] Sent: Friday, July 25, 2014 3:45 AM To: oxygenxml/userguide Subject: [userguide] DITA Map validation - profiling (#11)
Hi Mark,
For validating the UserGuide.ditamap we need to use also 7 profiling conditions. You can use the "Validate and check for completeness" action from the DITA Maps manager for UserGuide.ditamap and check the "Use DITAVAL filters", then select Other and add DITA/author.ditaval DITA/authorEclipse.ditaval DITA/developer.ditaval DITA/developerEclipse.ditaval DITA/editor.ditaval DITA/editorEclipse.ditaval DITA/svnClient.ditaval
These are 7 deliverables we want to produce from the UserGuide map and the integrity checks should be done for each of them - this will be what will happen when you add all these filter files there.
Currently we have issues with the install.upgrade key which is defined in the DITA/eppo.installation.upgrade.ditamap on the topicref "topics/upgrading.dita" but it is defined only for some product values and not for developer and developerEclipse.
Also, the DITA/topics/installation.options.dita refers to the make-oxygen-portable key and to the java-webstart-install key in the context of svnClient but these keys are not defined for svnClient.
The above validation action identifies the above issues so it will be good to use it from time to time to avoid these problems.
— Reply to this email directly or view it on GitHub https://github.com/oxygenxml/userguide/issues/11 . https://github.com/notifications/beacon/1695653__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcyMTg5MzQ3NywiZGF0YSI6eyJpZCI6Mzc5NDg0MDF9fQ==--d19b685b0e305e37afca8929102165d349a0c226.gif
georgebina
raducoravu
Hi Mark,
For validating the UserGuide.ditamap we need to use also 7 profiling conditions. You can use the "Validate and check for completeness" action from the DITA Maps manager for UserGuide.ditamap and check the "Use DITAVAL filters", then select Other and add DITA/author.ditaval DITA/authorEclipse.ditaval DITA/developer.ditaval DITA/developerEclipse.ditaval DITA/editor.ditaval DITA/editorEclipse.ditaval DITA/svnClient.ditaval
These are 7 deliverables we want to produce from the UserGuide map and the integrity checks should be done for each of them - this will be what will happen when you add all these filter files there.
Currently we have issues with the install.upgrade key which is defined in the DITA/eppo.installation.upgrade.ditamap on the topicref "topics/upgrading.dita" but it is defined only for some product values and not for developer and developerEclipse.
Also, the DITA/topics/installation.options.dita refers to the make-oxygen-portable key and to the java-webstart-install key in the context of svnClient but these keys are not defined for svnClient.
The above validation action identifies the above issues so it will be good to use it from time to time to avoid these problems.