Under Community Review

Enable XML elements and attributes in review space

Review space doesn't showcase XML elements or attributes, instead only content. XML elements & attributes should be showcased with reviewers to allow them reviewing the DITA tags.

In case of <hazardstatement type="danger"/> element, in review space it is not possible to showcase the type of hazard at all, which is very important as it involves human risk.

My idea is to enable "XML Source code" feature in Review space similar to draft space.

Muralikrishna Prodduturi
Parents

  • Hi, thanks for the post! I understand the use case to make sure a note is the right type. Regarding the implementation suggestion of enabling the XML view, Review Space itself is focused on non-technical (or at least non XML savvy) reviewers, requiring only an hour or two's training to make, say, a manager, completely productive in the tool. BUT, there are two ways to look at this to address the use case:

    • We are looking at ways to use the same "WYSIWYM" (What You See is What You Mean) view of the main content as in Draft Space. For example formatting a filepath element as monospace. And the note type could also be indicated visually, though as there are many note types possible, we'd want to focus on a couple of the clearest and most important/commonly used, for example "danger".
      This is more of a technical challenge than you might think, but we are working on this.

    • For reviews where it's really more of a code or peer review, and the reviewer needs to understand more of the element structure, then Draft Space would actually be the best tool to use, given that it also has the full commenting functionality as well as the ability to interact with the structure and see also the XML view.

    I'm marking this as "under community review" to mirror the fact that we're looking into the more informative WYSIWYM view of content itself, per the first bullet.

    Thanks again!

    Joe

Comment

  • Hi, thanks for the post! I understand the use case to make sure a note is the right type. Regarding the implementation suggestion of enabling the XML view, Review Space itself is focused on non-technical (or at least non XML savvy) reviewers, requiring only an hour or two's training to make, say, a manager, completely productive in the tool. BUT, there are two ways to look at this to address the use case:

    • We are looking at ways to use the same "WYSIWYM" (What You See is What You Mean) view of the main content as in Draft Space. For example formatting a filepath element as monospace. And the note type could also be indicated visually, though as there are many note types possible, we'd want to focus on a couple of the clearest and most important/commonly used, for example "danger".
      This is more of a technical challenge than you might think, but we are working on this.

    • For reviews where it's really more of a code or peer review, and the reviewer needs to understand more of the element structure, then Draft Space would actually be the best tool to use, given that it also has the full commenting functionality as well as the ability to interact with the structure and see also the XML view.

    I'm marking this as "under community review" to mirror the fact that we're looking into the more informative WYSIWYM view of content itself, per the first bullet.

    Thanks again!

    Joe

Children
No Data