Analyzing Map Validation Logs
I tested the new map validation feature by validating the full DITA 1.2 spec map, which is about as large a map as most people will have. The resulting validation large was long and includes a number of messages I know I can ignore, or least don't want look at. So to focus on specific errors here's what I did: 1. In the message result window I right clicked and did "Save results as XML". 2. Opened the XML file in Oxygen and applied the pretty print to it (so it would be easier to read). 3. Looked for distinguishing text in the message descriptions I wanted to ignore and then used this XPath to find all messages that didn't have those bits in their description: //incident[not(contains(description, 'subset')) and not(contains(description, 'key reference'))] This produces a list of <incident> elements in the XQuery result list. I then just selected each search result in turn and it took me right to the log message I cared about. I could then use the "Open file at cursor" feature to open the file in question. Took me about 5 minutes to find and fix about 10 bad links scattered throughout several hundred topics and a number of maps. Cheers, E. -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com
Hi Eliot, This is an interesting way to filter problems. Maybe you have also sorted the messages by description and then remove a part of them from the output view. We'll also try to add some more checkboxes in the dialog which configures the DITA Map validation options so that users can have more control and uncheck the warnings which are less important to them. Regards, Radu Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 9/15/2010 8:09 PM, Eliot Kimber wrote:
I tested the new map validation feature by validating the full DITA 1.2 spec map, which is about as large a map as most people will have.
The resulting validation large was long and includes a number of messages I know I can ignore, or least don't want look at.
So to focus on specific errors here's what I did:
1. In the message result window I right clicked and did "Save results as XML".
2. Opened the XML file in Oxygen and applied the pretty print to it (so it would be easier to read).
3. Looked for distinguishing text in the message descriptions I wanted to ignore and then used this XPath to find all messages that didn't have those bits in their description:
//incident[not(contains(description, 'subset')) and not(contains(description, 'key reference'))]
This produces a list of<incident> elements in the XQuery result list.
I then just selected each search result in turn and it took me right to the log message I cared about. I could then use the "Open file at cursor" feature to open the file in question.
Took me about 5 minutes to find and fix about 10 bad links scattered throughout several hundred topics and a number of maps.
Cheers,
E.
I did not sort the messages in this case but that might be handy in some cases. Cheers, E. On 9/16/10 1:53 AM, "Radu Coravu" <radu_coravu@sync.ro> wrote:
Hi Eliot,
This is an interesting way to filter problems. Maybe you have also sorted the messages by description and then remove a part of them from the output view. We'll also try to add some more checkboxes in the dialog which configures the DITA Map validation options so that users can have more control and uncheck the warnings which are less important to them.
Regards, Radu
Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com
On 9/15/2010 8:09 PM, Eliot Kimber wrote:
I tested the new map validation feature by validating the full DITA 1.2 spec map, which is about as large a map as most people will have.
The resulting validation large was long and includes a number of messages I know I can ignore, or least don't want look at.
So to focus on specific errors here's what I did:
1. In the message result window I right clicked and did "Save results as XML".
2. Opened the XML file in Oxygen and applied the pretty print to it (so it would be easier to read).
3. Looked for distinguishing text in the message descriptions I wanted to ignore and then used this XPath to find all messages that didn't have those bits in their description:
//incident[not(contains(description, 'subset')) and not(contains(description, 'key reference'))]
This produces a list of<incident> elements in the XQuery result list.
I then just selected each search result in turn and it took me right to the log message I cared about. I could then use the "Open file at cursor" feature to open the file in question.
Took me about 5 minutes to find and fix about 10 bad links scattered throughout several hundred topics and a number of maps.
Cheers,
E.
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
-- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com
Hi Eliot, Please also note the delete button on the right side, it allows you to remove some of the presented errors so you can focus only on the remaining ones - in your case you can remove the warnings related with the @rev values. BTW, where did you get the DITA 1.2 spec from? I followed http://docs.oasis-open.org/dita/v1.2/spec/DITA1.2-spec.html and downloaded http://docs.oasis-open.org/dita/v1.2/cd03/spec/DITA1.2-spec.zip then tried to open the DITA1.2-spec/dita1.2-complete.ditamap file. This refers to learningTraining_elements.ditamap that refers to keys-learningTraining.ditamap. This later DITA map file does not exist. Do you know where can I get it from? Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 9/16/10 4:27 PM, Eliot Kimber wrote:
I did not sort the messages in this case but that might be handy in some cases.
Cheers,
E.
On 9/16/10 1:53 AM, "Radu Coravu"<radu_coravu@sync.ro> wrote:
Hi Eliot,
This is an interesting way to filter problems. Maybe you have also sorted the messages by description and then remove a part of them from the output view. We'll also try to add some more checkboxes in the dialog which configures the DITA Map validation options so that users can have more control and uncheck the warnings which are less important to them.
Regards, Radu
Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com
On 9/15/2010 8:09 PM, Eliot Kimber wrote:
I tested the new map validation feature by validating the full DITA 1.2 spec map, which is about as large a map as most people will have.
The resulting validation large was long and includes a number of messages I know I can ignore, or least don't want look at.
So to focus on specific errors here's what I did:
1. In the message result window I right clicked and did "Save results as XML".
2. Opened the XML file in Oxygen and applied the pretty print to it (so it would be easier to read).
3. Looked for distinguishing text in the message descriptions I wanted to ignore and then used this XPath to find all messages that didn't have those bits in their description:
//incident[not(contains(description, 'subset')) and not(contains(description, 'key reference'))]
This produces a list of<incident> elements in the XQuery result list.
I then just selected each search result in turn and it took me right to the log message I cared about. I could then use the "Open file at cursor" feature to open the file in question.
Took me about 5 minutes to find and fix about 10 bad links scattered throughout several hundred topics and a number of maps.
Cheers,
E.
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
I'm working with the DITA spec source from the TC's SVN repository. Cheers, E. On 9/17/10 5:04 AM, "George Cristian Bina" <george@oxygenxml.com> wrote:
Hi Eliot,
Please also note the delete button on the right side, it allows you to remove some of the presented errors so you can focus only on the remaining ones - in your case you can remove the warnings related with the @rev values.
BTW, where did you get the DITA 1.2 spec from? I followed http://docs.oasis-open.org/dita/v1.2/spec/DITA1.2-spec.html and downloaded http://docs.oasis-open.org/dita/v1.2/cd03/spec/DITA1.2-spec.zip then tried to open the DITA1.2-spec/dita1.2-complete.ditamap file. This refers to learningTraining_elements.ditamap that refers to keys-learningTraining.ditamap. This later DITA map file does not exist. Do you know where can I get it from?
Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com
On 9/16/10 4:27 PM, Eliot Kimber wrote:
I did not sort the messages in this case but that might be handy in some cases.
Cheers,
E.
On 9/16/10 1:53 AM, "Radu Coravu"<radu_coravu@sync.ro> wrote:
Hi Eliot,
This is an interesting way to filter problems. Maybe you have also sorted the messages by description and then remove a part of them from the output view. We'll also try to add some more checkboxes in the dialog which configures the DITA Map validation options so that users can have more control and uncheck the warnings which are less important to them.
Regards, Radu
Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com
On 9/15/2010 8:09 PM, Eliot Kimber wrote:
I tested the new map validation feature by validating the full DITA 1.2 spec map, which is about as large a map as most people will have.
The resulting validation large was long and includes a number of messages I know I can ignore, or least don't want look at.
So to focus on specific errors here's what I did:
1. In the message result window I right clicked and did "Save results as XML".
2. Opened the XML file in Oxygen and applied the pretty print to it (so it would be easier to read).
3. Looked for distinguishing text in the message descriptions I wanted to ignore and then used this XPath to find all messages that didn't have those bits in their description:
//incident[not(contains(description, 'subset')) and not(contains(description, 'key reference'))]
This produces a list of<incident> elements in the XQuery result list.
I then just selected each search result in turn and it took me right to the log message I cared about. I could then use the "Open file at cursor" feature to open the file in question.
Took me about 5 minutes to find and fix about 10 bad links scattered throughout several hundred topics and a number of maps.
Cheers,
E.
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
-- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com
On 2010-09-16 08:53, Radu Coravu wrote:
We'll also try to add some more checkboxes in the dialog which configures the DITA Map validation options so that users can have more control and uncheck the warnings which are less important to them.
Hi Radu, That would be useful indeed. I find the feature very useful and it has helped me spot a number of potential problems quickly, but the output is full of complaints about keys that are actually working fine. It seems to work OK when <keydef> elements are used to associate a key with a file name like this: <keydef keys="name-of-key" href="path/to/file.dita"/> But it doesn't seem to understand that <keydef> elements can also be used to define variables like this: <keydef keys="version"> <topicmeta> <keywords> <keyword>2.0.1.0</keyword> </keywords> </topicmeta> </keydef> I use this approach a lot to maintain variable definitions in the master map file for a project, and then reference them in text like this: “What's new in <keyword keyref="productname"/> <keyword keyref="version"/>” When used this way, the <oXygen/> map validation routine complains there's no file associated with the key, but in this case that's not necessary and the text is substituted as intended in all output formats. Should I be doing something differently to please <oXygen/>, or does the tool need to learn this way of using keys? Regards, Roger
Hi Roger, Thanks for pointing out this situation. If you know of others, they are welcomed. So the smart thing to do for the validation checker would be not to report any error if the key definition has no reference defined on it. We'll probably fix this also in a minor Oxygen 12 release. So watch this feed to be notified when this happens: http://www.oxygenxml.com/rssBuildID.xml Regards, Radu Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 9/17/2010 12:39 AM, Roger wrote:
On 2010-09-16 08:53, Radu Coravu wrote:
We'll also try to add some more checkboxes in the dialog which configures the DITA Map validation options so that users can have more control and uncheck the warnings which are less important to them.
Hi Radu,
That would be useful indeed. I find the feature very useful and it has helped me spot a number of potential problems quickly, but the output is full of complaints about keys that are actually working fine.
It seems to work OK when<keydef> elements are used to associate a key with a file name like this:
<keydef keys="name-of-key" href="path/to/file.dita"/>
But it doesn't seem to understand that<keydef> elements can also be used to define variables like this:
<keydef keys="version"> <topicmeta> <keywords> <keyword>2.0.1.0</keyword> </keywords> </topicmeta> </keydef>
I use this approach a lot to maintain variable definitions in the master map file for a project, and then reference them in text like this:
“What's new in<keyword keyref="productname"/> <keyword keyref="version"/>”
When used this way, the<oXygen/> map validation routine complains there's no file associated with the key, but in this case that's not necessary and the text is substituted as intended in all output formats.
Should I be doing something differently to please<oXygen/>, or does the tool need to learn this way of using keys?
Regards,
Roger
participants (4)
-
Eliot Kimber -
George Cristian Bina -
Radu Coravu -
Roger