In the xml, which way is better when define data in content or in the attribute ? Thanks
<order id='' orderBy='' orderTime=''>
.....
</order>
or
<order id=''>
.....
<orderBy>.. </orderBy>
<orderTime>...</orderTime>
</order>
Depends what the data will be. If the data are just simple strings then the first one will be fine.
The second one is important to use if you need to in the future wrap in CDATA. So if the data is long or may contain html in the future then I suggest using the second form. If you look at twitter's XML feed, you will notice that they prefer using an element for almost all of their properties. Using elements give you flexibility in the future if you need to add more multiple elements of the same type.
Here is an article you should read that discusses this topic.
My advice is to perhaps keep your id in an attribute but the rest in an element.
In general, I prefer to use elements instead of attributes, as elements can later be expanded upon (the "extensible" part of XML). However, when you have a rather specific data type as with both of your examples here, you're probably best off keeping them as attributes - especially if orderTime is a standard XML dateTime type.
I would like to add one more point, if CDATA is not issue, then I prefer as attribute than Element. Order Id, date, count etc., should be attributes. Order Items should be Elements.
Generally speaking, you use an attribute if:
there is only one item (of that name) within the parent node
Otherwise, you use an element if:
there can be more than one item (of that name) within the node, or
the item is complex, i.e., may contain attibutes or sub-elements itself
Related
I need to query the names of "available" sub elements of an element node in DOM.
For example if schema says "There can be age, name, occupation elements under person element." then I wanna function like this,
import org.w3c.dom.Element;
Element person_element;
String[] names_of_available_sub_element =
get_available_sub_element_names(person_element);
which makes
names_of_available_sub_element == {"age", "name", "occupation"}.
How can I implement this function?
This isn't easy, but it can be done if you're prepared to put a lot of work in.
There are a number of approaches to getting information from an XSD schema. You could try and process the XSD source code, but I wouldn't recommend that, because there are so many things you have to take into account (wildcards, substitution groups, types derived by restriction and extension, and so on). A better approach is to use some kind of API that gives you access to the information in digested form. For that, some possible suggestions are:
(a) Xerces gives you a Java API providing programmatic access to the compiled schema.
(b) Saxon gives you two possibilities: (i) the SCM file, which is an XML representation of the compiled schema, and (ii) an XPath API giving programmatic access to the compiled schema using extension functions.
Do remember that knowing you're at a "person" element isn't (in the general case) enough to determine what the permitted children are. That's because there can be global and local elements using the name "person", but with different types. Whether this is a problem in your case depends on what you are trying to achieve, which you haven't really explained in much detail.
I am wondering if XMLUNIT provides a way to ignore some of the elements present in the XML before doing the comparison.For example, if I want to ignore field which is randomly generated by the server.Is there anything available out of the box in XMLUnit to ignore certian elements or I need to write a custom DifferenceListener ?
Also, does it provide the elements name that do not match? If not, then what could be the best way to compare two XML which can allow me to ignore some elements and also provide me the elements names/values that does not match?
I'm afraid a custom DifferenceListener is the only way to go right now. There is a feature request for XMLUnit2 (https://github.com/xmlunit/xmlunit/issues/26) that hasn't been implemented, yet.
Implementing the DifferenceListener may be a bit cumbersome since you'll not only receive Differences for the elements you want to ignore but most likely also receive them for the number of children of the parent element.
Each Difference contains NodeDetails for the nodes seen on the test and control side and the NodeDetail contains the DOM Node (which will be an Element in your case).
I am trying to validate an xml against an xsd in java.
In XSD one of the field(tax_id) is defined as manadatory element.
But in my scenario I pass an xml to another component, that component fills the manadatory
field(tax_id).
Before sending that xml to the next component, I have to validate that xml against the xsd.
As, in that XSD element tax_id is defined as mandatory element, I get exception for not filling mandatory element (tax_id).
I can create a new xsd by making tax_id as optional field, but with this we would be having 2 xsds.
Is there any way to skip/ignore few elements while validating in java?
In general, no. The purpose of the XSD is to specify the rules that the document must meet, in order to be valid. You can't ignore or skip some of those rules. If you could, you'd probably have other problems. For example, if required elements were really optional (or could be) then technically any element that was supposed to contain a bunch of other elements could be empty (and still valid) under that more lax validation.
In your situation, you probably have two options:
Change your workflow - make sure the first component populates the XML with the empty tax_id. Then it will validate.
Introduce a second schema - one earlier in the "pipeline" of processing, that doesn't require tax_id. Then validate against that.
I have read a similar topic on the matter:
getting the minOccurs attribute using XSOM from an element
but the answer seemed a bit suboptimal, especially when there are hundreds of elements in one xsd file. Is it really the only way to do this, or is there a simpler way?
I would like to retrieve it from XSElementDecl if it's at all possible.
You can't. It's not a property of the element declaration, it's a property of the element particle, which is the relationship between an element declaration and the content model in which it is used.
Now, if the element declaration is a local declaration then it's true enough it can only be used in one content model, so the declaration and the particle are one-to-one, and in the SCM defined in XSD 1.1 it seems that if {variety} is local then you can get {parent} to find the containing model group, and then go back over the particles of this model group. But XSOM doesn't seem to reflect the {parent} property, which is not surprising, because it's not there in XSD 1.0, and there doesn't seem to be anything corresponding to the {scope} property either.
So, the API doesn't seem to allow navigation from the Element declaration to the particles that use that declaration. But then, how did you find the Element declaration if it wasn't via the particle?
I know this isn't really what XPath is for but if I have a HashMap of XPath expressions to values how would I go about building an XML document. I've found dom-4j's
DocumentHelper.makeElement(branch, xpath) except it is incapable of creating attributes or indexing. Surely a library exists that can do this?
Map xMap = new HashMap();
xMap.put("root/entity/#att", "fooattrib");
xMap.put("root/array[0]/ele/#att", "barattrib");
xMap.put("root/array[0]/ele", "barelement");
xMap.put("root/array[1]/ele", "zoobelement");
would result in:
<root>
<entity att="fooattrib"/>
<array><ele att="barattrib">barelement</ele></array>
<array><ele>zoobelement</ele></array>
</root>
I looked for something similar a few years ago - a sort of writeable XPath. In the end, having not found anything, I hacked up something which essentially built up the XML document by adding new nodes to parent expressions:
parent="/" element="root"
parent="/root" element="entity"
parent="/root/entity" attribute="att" value="fooattrib"
parent="/root" element="array"
parent="/root" element="ele" text="barelement"
(This was itself to be governed by an XML configuration file, hence the appearance of above.)
It would be tempting to try an automate some of this to just take the last path element, and make something of it, but I always felt that there were XPath expressions I could write which such a dumbheaded approach would get wrong.
Another approach I considered, though did not implement (the above was "good enough"), was to use the excellent Jaxen to generate elements that did not exist, on the fly if it didn't already exist.
From the Jaxen FAQ:
The only thing required is an implementation of the interface org.jaxen.Navigator. Not all of the interface is required, and a default implementation, in the form of org.jaxen.DefaultNavigator is also provided.
The DOMWriterNavigator would wrap and existing DOMNavigator, and then use the makeElement method if the element didn't exist. However, even with this approach,
you'd probably have to do some pre/post processing of the XPath query for things like attributes and text() functions.
The best I was able to come up with is to use a JAXB implementation, which will marshall/unmarshal objects to xml and then I used Dozer (http://dozer.sourceforge.net/documentation/mapbackedproperty.html) to map the xpaths which were keys in a map to the JAXB object method setters.
<mapping type="one-way" map-id="TC1">
<class-a>java.util.Map</class-a>
<class-b>org.example.Foo</class-b>
<field>
<a key="root/entity/#att">this</a>
<b>Foo.entity.att</b>
<a-hint>java.lang.String</a-hint>
</field>
It's more of a two step solution, but really worked for me.
I also wanted same kind of requirement where nature is so dynamic and dont want to use XSLT or any object mapping frameworks, so i've implemented this code in java and written blog on it please visit,
http://ganesh-kandisa.blogspot.com/2013/08/dynamic-xml-transformation-in-java.html
or fork code at git repository,
https://github.com/TheGanesh/DynamicXMLTransformer