Oxygen XML Forum

I am having a problem where I have lots of elements that have only attribute children. The problem is that when i pretty-print the xml document, Oxygen reorders the attributes. I know that technically attributes aren't ordered, but as a matter of practice, it is extremely disconcerting to the developer if important attributes like id or name are not where they were when the developer created the elements.

i.e., I have the following elements:

<Transition input="approve" nextState="4" description="submitted document is approved"/>
<Transition input="return" nextState="3" description="submitted document was returned for modifications"/>
<Transition input="reject" nextState="6" description="submitted document was rejected"/>

The input attribute serves as the id for the transition, and in order to find a particular Transition element, I scan for the transition that has a particular input attribute value.

If I pretty-print the document this is from, it ends up like:

<Transition description="submitted document is approved" input="approve" nextState="4"/>
<Transition description="submitted document was returned for modifications" input="return" nextState="3"/>
<Transition description="submitted document was rejected" input="reject" nextState="6"/>

You can imagine that if the description were long, or there were 10 or so attributes, it would be very difficult to find the Transition that has a particular input.

In short, while attribute order doesn't matter to a parser, it is at times extremely important to authors of XML documents, since the first attribute often serves as an identifier for the element. In fact, for many of the documents that we are creating, we cannot use Oxygen's pretty print feature, since the documents become unreadable.

Have I missed some way to configure this in Oxygen (I'm using latest version), or have you thought of maintaining the order of attributes, or at least providing this an option?

Hi,

I filed your request as an enhancement for the pretty print component.
There is also another indenting option "Indent selection" in the contextual menu that performs just line indenting, that is no attribute reorder, no line breaks inserted/removed.
Also have you considered the XPath search support ? For instance if you enter in the XPath input something like: then you will see the matched Transtion nodes in the result panel and you can click on a hit and the corresponding match in the document will be highlighted. This can be though as kind of outliner support driven by your specific XPath query.

Hope that helps,
George

george wrote:Hi,

I filed your request as an enhancement for the pretty print component.
There is also another indenting option "Indent selection" in the contextual menu that performs just line indenting, that is no attribute reorder, no line breaks inserted/removed.
Also have you considered the XPath search support ? For instance if you enter in the XPath input something like:

Code: Select all

//Transition/@description[../@input='approve']

then you will see the matched Transtion nodes in the result panel

Code: Select all

- [ test.xml] /test[1]/Transition[1]/@description - submitted document is approved (3:1)

and you can click on a hit and the corresponding match in the document will be highlighted. This can be though as kind of outliner support driven by your specific XPath query.

Hope that helps,
George

Hi George,

Thanks for filing this as a request for enhancement. I look forward to seeing this. Unfortunately neither of the alternatives you proposed are feasible. I need to the pretty print in order to pretty print xml files with, for example, no whitespace between elements at all. Doing this manually with indent selection would take longer than manually inserting tabs.

Searching for an attribute using xpath would also take far longer than finding the attribute manually by eye with attributes all jumbled up. For the moment I and my team are just not using the pretty print at all, and have to manually pretty print it ourselves, but this is obviously very inconvenient.

thanks,

n.