Normalization in DOM parsing with java - how does it work?

The rest of the sentence is:

where only structure (e.g., elements, comments, processing instructions, CDATA sections, and entity references) separates Text nodes, i.e., there are neither adjacent Text nodes nor empty Text nodes.

This basically means that the following XML element

hello 
wor
ld

could be represented like this in a denormalized node:

Element foo
    Text node: ""
    Text node: "Hello "
    Text node: "wor"
    Text node: "ld"

When normalized, the node will look like this

Element foo
    Text node: "Hello world"

And the same goes for attributes: , comments, etc.

http://stackoverflow.com/questions/13786607/normalization-in-dom-parsing-with-java-how-does-it-work

Which is the best library for XML parsing in java [closed]

Actually Java supports 4 methods to parse XML out of the box:

DOM Parser/Builder: The whole XML structure is loaded into memory and you can use the well known DOM methods to work with it. DOM also allows you to write to the document with Xslt transformations. Example:

    DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
    factory.setValidating(true);
    factory.setIgnoringElementContentWhitespace(true);
    try {
        DocumentBuilder builder = factory.newDocumentBuilder();
        File file = new File("test.xml");
        Document doc = builder.parse(file);
        // Do something with the document here.
    } catch (ParserConfigurationException e) {
    } catch (SAXException e) {
    } catch (IOException e) { 
    }

SAX Parser: Solely to read a XML document. The Sax parser runs through the document and calls callback methods of the user. There are methods for start/end of a document, element and so on. They're defined in org.xml.sax.ContentHandler and there's an empty helper class DefaultHandler.

    SAXParserFactory factory = SAXParserFactory.newInstance();
    factory.setValidating(true);
    try {
        SAXParser saxParser = factory.newSAXParser();
        File file = new File("test.xml");
        saxParser.parse(file, new ElementHandler());    // specify handler
    }
    catch(ParserConfigurationException e1) {
    }
    catch(SAXException e1) {
    }
    catch(IOException e) {
    }

StAx Reader/Writer: This works with a datastream oriented interface. The program asks for the next element when it's ready just like a cursor/iterator. You can also create documents with it. Read document:

    FileInputStream fis = null;
    try {
        fis = new FileInputStream("test.xml");
        XMLInputFactory xmlInFact = XMLInputFactory.newInstance();
        XMLStreamReader reader = xmlInFact.createXMLStreamReader(fis);
        while(reader.hasNext()) {
            reader.next(); // do something here
        }
    }
    catch(IOException exc) {
    }
    catch(XMLStreamException exc) {
    }

Write document:

    FileOutputStream fos = null;
    try {
        fos = new FileOutputStream("test.xml");
        XMLOutputFactory xmlOutFact = XMLOutputFactory.newInstance();
        XMLStreamWriter writer = xmlOutFact.createXMLStreamWriter(fos);
        writer.writeStartDocument();
        writer.writeStartElement("test");
        // write stuff
        writer.writeEndElement();
        writer.flush();
    }
    catch(IOException exc) {
    }
    catch(XMLStreamException exc) {
    }
    finally {
    }

JAXB: The newest implementation to read XML documents: Is part of Java 6 in v2. This allows us to serialize java objects from a document. You read the document with a class that implements a interface to javax.xml.bind.Unmarshaller (you get a class for this from JAXBContext.newInstance). The context has to be initialized with the used classes, but you just have to specify the root classes and don't have to worry about static referenced classes. You use annotations to specify which classes should be elements (@XmlRootElement) and which fields are elements(@XmlElement) or attributes (@XmlAttribute, what a surprise!)

    RootElementClass adr = new RootElementClass();
    FileInputStream adrFile = null;
    try {
        adrFile = new FileInputStream("test");
        JAXBContext ctx = JAXBContext.newInstance(RootElementClass.class);
        Unmarshaller um = ctx.createUnmarshaller();
        adr = (RootElementClass) um.unmarshal(adrFile);
    }
    catch(IOException exc) {
    }
    catch(JAXBException exc) {
    }
    finally {
    }

Write document:

    FileOutputStream adrFile = null;
    try {
        adrFile = new FileOutputStream("test.xml");
        JAXBContext ctx = JAXBContext.newInstance(RootElementClass.class);
        Marshaller ma = ctx.createMarshaller();
        ma.marshal(..);
    }
    catch(IOException exc) {
    }
    catch(JAXBException exc) {
    }
    finally {
    }

Examples shamelessly copied from some old lecture slides ;-)

Edit: About "which API shoild I use?". Well it depends - not all APIs have the same capabilities as you see, but if you have control over the classes you use to map the XML document JAXB is my personal favorite, really elegant and simple solution (though I haven't used it for really large documents, it could get a bit complex). SAX is pretty easy to use too and just stay away from DOM if you don't have a really good reason to use it - old, clunky API in my opinion. I don't think there are any modern 3rd party libraries that feature anything especially useful that's missing from the stl and the standard libraries have the usual advantages of being extremely well tested, documented and stable.

http://stackoverflow.com/questions/5059224/which-is-the-best-library-for-xml-parsing-in-java

1.2 Identifying Time Zones and Zone Offsets

[XML Schema] follows the [ISO 8601] standard for its lexical representation. Date and time values in ISO 8601 are field-based using the definitions above and can indicate (or omit) the zone offset from UTC. A zone offset is not the same thing as a time zone, and the difference can be important. XML Schema only supports zone offset, but, confusingly, calls it time zone, see for example section 3.2.8.1, lexical representation in [XML Schema].
Although ISO 8601 is expressed in terms of the Gregorian calendar, it can be used to represent values in any calendar system. The presentation of date and time values to end users using different calendar and timekeeping systems is separate from the lexical representation.
What is a "zone offset"? A zone offset is the difference in hours and minutes between a particular time zone and UTC. In ISO 8601, the particular zone offset can be indicated in a date or time value. The zone offset can be Z for UTC or it can be a value "+" or "-" from UTC. For example, the value 08:00-08:00 represents 8:00 AM in a time zone 8 hours behind UTC, which is the equivalent of 16:00Z (8:00 plus eight hours). The value 08:00+08:00 represents the opposite increment, or midnight (08:00 minus eight hours).
What is a "time zone"? A time zone is an identifier for a specific location or region which translates into a combination of rules for calculating the UTC offset. For example, when a website maintaining a group calendar in the United States schedules a recurring meeting for 08:00 Pacific Time, it is referring to what is sometimes known as wall time (so called because that is the time shown "on the clock (or calendar) on the wall"). This is not equivalent to either 08:00-08:00 or 08:00-07:00, because Pacific Time does not have a fixed offset from UTC; instead, the offset changes during the course of the year. As mentioned before, XML Schema only supports zone offsets, and it does not make the terminological distinction between zone offset and time zone. So a wall time expressed as an XML Schema time value, must choose which zone offset to use. This may have the unintended effect of causing a scheduled event to shift by an hour (or more) when wall time changes to or from Daylight/Summer time.
To complicate matters, the rules for computing when daylight savings takes effect may be somewhat complex and may change from year to year or from location to location. In the United States, the state of Indiana, for example, does not follow daylight savings time, but this will change in April 2006. See: http://www.mccsc.edu/time.html for further information. The Northern and Southern hemispheres perform Daylight/Summer Time adjustments during opposing times during the year (corresponding to seasonal differences in the two hemispheres).
To capture these situations, a calendar system must use an ID for the time zone. The most definitive reference for dealing with wall time is the TZ database (also known as the "Olson time zone database" [tzinfo]), which is used by systems such as various commercial UNIX operating systems, Linux, Java, CLDR, ICU, and many other systems and libraries. In the TZ database, "Pacific Time" is denoted with the ID America/Los_Angeles. The TZ database also supplies aliases among different IDs; for example, Asia/Ulan Bator is equivalent to Asia/Ulaanbaatar. From these alias relations, a canonical identifier can be derived. The Common Locale Data Repository [CLDR] can be used to provide a localized form for the IDs: see Appendix J in [UAX 35].

Webservices - SOAP vs. “XML over HTTP”

SOAP is just a specialization of XML over HTTP and that response you posted does indeed look like a SOAP response (a SOAP fault actually).

This looks like a big misunderstanding, so don't assume they are pulling your leg. Try asking your question in a different way.

As for the WSDL, if this is indeed a 100% SOAP web service, do note that it is not mandatory to have a WSDL for a SOAP web service.

A web service is just an application that exposes a set of operations over the network. In order to call these operations you need to know what their name is, what parameters they expect, what types the parameters have etc, so that you know how to build your client stub.

This means the web service needs to be documented or else you would not know how to write the code that interact with the web service. This documentation can be a Word document or a PDF and you could build the client manually from that (which involves writing a lot of plumbing code for that client stub of yours) OR the documentation could be a WSDL file which unlike a PDF or Word document can be fed to a tool to generate the stub plumbing code for you automatically.

The WSDL describes the web service - and it's good practice to provide one - but the web service exists separately from the WSDL.

http://stackoverflow.com/questions/10521456/webservices-soap-vs-xml-over-http

Should dateTime elements include time zone information in SOAP messages?

Given the following sentences from the w3c schema documentation:

"Local" or untimezoned times are presumed to be the time in the timezone of some unspecified locality as prescribed by the appropriate legal authority;

and

When a timezone is added to a UTC dateTime, the result is the date and time "in that timezone".

it does not sound like there is a definitive answer to this. I would assume that it is the usual ambiguity: Both versions are principally valid, and the question of what version to use depends on the configuration/behavior/expectations of the system one is interfacing with.
And even if there where a definitive answer, I would definitely not rely on it, but rather expect that every other web service and library had its own way of dealing with this :/

 http://stackoverflow.com/questions/1642636/should-datetime-elements-include-time-zone-information-in-soap-messages

xml schema Timezone

I think that your interpretation might be off; I can't see how you ended up with GMT+13:00 from 13:00:00Z.
The XSD spec gives the following example:

2002-10-10T12:00:00+05:00 is 2002-10-10T07:00:00Z 
2002-10-10T00:00:00+05:00 is 2002-10-09T19:00:00Z

A nonnegative duration means that the time zone is ahead; negative is behind.
Assuming that the timestamp was taken at midnight (12:00AM), and it matched 13:00:00Z, then you could offset this either ahead or behind:

Behind: 2012-02-04T00:00:00-13:00 is 2012-02-04T13:00:00Z
Ahead:  2012-02-05T00:00:00+11:00 is 2012-02-04T13:00:00Z

The only one valid is the ahead (there is no -13); As to what is in that time zone, take a look here.

http://stackoverflow.com/questions/9950406/xml-schema-timezone