Basic XML question

[toni896]

Can you have more than 1 Root element in a File.
I always been under the impression 1 Root element per file only, howeverI have just got some data which doesn't match out XML tree,

First example
<Root>
<MessageType>all the repeating stuff in here</MessageType>
<MessageType>all the repeating stuff in here</MessageType>
<MessageType>all the repeating stuff in here</MessageType>
</Root>


Second example
the Data I have just received

<Root>all the repeating stuff in here</Root>
<Root>all the repeating stuff in here</Root>
<Root>all the repeating stuff in here</Root>

My question is,

Is it valid to receive a file that contains a reapeating Root element ?

[Size Nine Elm]

No you can't.

Its a bit of a pain, and prevents doing things like log files in XML since you can't just append new elements.

You can always leave a header root element open, and append subsequent elements as child elements, and finally close the root element when you close the file, but this leaves the XML inconsistent until you finally close it.

[toni896]

Cheers, it's not a problem as all my stuff is based around 1 file 1 root element,
it's just our supplier has sent us a file containing multiple root elements.

I was worried i'd mis understood something a long time ago and needed to do a lot of work to correct it.

[ATG]

"One file" => "one root" is not the same as saying "One XML document" => "one root". The latter is true, but surely the former isn't? Why can't one file can contain several consecutive XML documents? (Also don't see the problem with log files, except for the verbosity being even worse than it usually is with XML.)

Edited by ATG on Friday 2nd March 11:05

[dern]

ATG said:

(Also don't see the problem with log files, except for the verbosity being even worse than it usually is with XML.)

SNE explained that one. While you can append records after the opening root element the xml file won't be well formed until you close the root element. If I needed an xml log file I'd be tempted to write a service that accepted logging messages and kept them in memory and wrote a well formed xml document from that on some event.

[TheGroover]

toni896 said:

Can you have more than 1 Root element in a File.
I always been under the impression 1 Root element per file only, howeverI have just got some data which doesn't match out XML tree,

First example
<Root>
<MessageType>all the repeating stuff in here</MessageType>
<MessageType>all the repeating stuff in here</MessageType>
<MessageType>all the repeating stuff in here</MessageType>
</Root>


Second example
the Data I have just received

<Root>all the repeating stuff in here</Root>
<Root>all the repeating stuff in here</Root>
<Root>all the repeating stuff in here</Root>

My question is,

Is it valid to receive a file that contains a reapeating Root element ?

You can, but you'd need to load it into an XMLNodeList rather than an XMLDocument in your code if you need to parse it.

[ATG]

dern said:

ATG said:

(Also don't see the problem with log files, except for the verbosity being even worse than it usually is with XML.)

SNE explained that one. While you can append records after the opening root element the xml file won't be well formed until you close the root element. If I needed an xml log file I'd be tempted to write a service that accepted logging messages and kept them in memory and wrote a well formed xml document from that on some event.

You've missed the point. The log file can be a set of well formed XML documents not one XML docuemnt that is left open. I don't see the problem with one file containing more than one XML document. Each time you log to the log file it will add a complete XML document to the file, not a single new element.

[dern]

ATG said:

dern said:

ATG said:

(Also don't see the problem with log files, except for the verbosity being even worse than it usually is with XML.)

SNE explained that one. While you can append records after the opening root element the xml file won't be well formed until you close the root element. If I needed an xml log file I'd be tempted to write a service that accepted logging messages and kept them in memory and wrote a well formed xml document from that on some event.

You've missed the point. The log file can be a set of well formed XML documents not one XML docuemnt that is left open. I don't see the problem with one file containing more than one XML document. Each time you log to the log file it will add a complete XML document to the file, not a single new element.

I understood that point but didn't think you were serious as it would be spectacularly inefficient and pointless. I agree that it's probably possible though.

[ATG]

dern said:

ATG said:

dern said:

ATG said:

(Also don't see the problem with log files, except for the verbosity being even worse than it usually is with XML.)

SNE explained that one. While you can append records after the opening root element the xml file won't be well formed until you close the root element. If I needed an xml log file I'd be tempted to write a service that accepted logging messages and kept them in memory and wrote a well formed xml document from that on some event.

You've missed the point. The log file can be a set of well formed XML documents not one XML docuemnt that is left open. I don't see the problem with one file containing more than one XML document. Each time you log to the log file it will add a complete XML document to the file, not a single new element.

I understood that point but didn't think you were serious as it would be spectacularly inefficient and pointless. I agree that it's probably possible though.

What other point could I possibly have been making? XML is always spectaculary inefficient in terms of the size of the document compared to the data it contains. That is a given.

[dern]

ATG said:

What other point could I possibly have been making? XML is always spectaculary inefficient in terms of the size of the document compared to the data it contains. That is a given.

In some cases the benefits of the inherent structure outweighs the verbosity of the format but in your example there is no structure so no advantage. That's why I didn't think you were serious.

[ATG]

dern said:

ATG said:

What other point could I possibly have been making? XML is always spectaculary inefficient in terms of the size of the document compared to the data it contains. That is a given.

In some cases the benefits of the inherent structure outweighs the verbosity of the format but in your example there is no structure so no advantage. That's why I didn't think you were serious.

Wasn't my example though. I too can't see any structural benefit in using XML for a log file. Log files are lists, not trees. Clearly an unclosed XML document containing a great list of log elements isn't a well-formed XML document. If you insist on having an XML based log file, all I suggested was having a single file containg list of XML documents rather than a list of XML elements. That way at least the XML would be well formed.

[GreenV8S]

dern said:

in your example there is no structure

There could be a lot of structure in a log file though, and XML would be a credible way to represent this. Not the most concise format you could imagine, but that isn't always the most important concern.

[ATG]

GreenV8S said:

dern said:

in your example there is no structure

There could be a lot of structure in a log file though, and XML would be a credible way to represent this. Not the most concise format you could imagine, but that isn't always the most important concern.

Oh good! Someone else to argue with. Let's see now ... uhm ... NO!

[dern]

GreenV8S said:

dern said:

in your example there is no structure

There could be a lot of structure in a log file though, and XML would be a credible way to represent this. Not the most concise format you could imagine, but that isn't always the most important concern.

Right but if you read ATG's suggestion on how to use xml in an appending log file he's saying that you could get around not always having a well formed layout at all times by effectively appending a new xml document to the log file for each log message. This solves the original problem but doesn't provide much in the way of structure because each message is represented by a wholly separate xml document.

[dern]

ATG said:

dern said:

ATG said:

What other point could I possibly have been making? XML is always spectaculary inefficient in terms of the size of the document compared to the data it contains. That is a given.

In some cases the benefits of the inherent structure outweighs the verbosity of the format but in your example there is no structure so no advantage. That's why I didn't think you were serious.

Wasn't my example though. I too can't see any structural benefit in using XML for a log file. Log files are lists, not trees. Clearly an unclosed XML document containing a great list of log elements isn't a well-formed XML document. If you insist on having an XML based log file, all I suggested was having a single file containg list of XML documents rather than a list of XML elements. That way at least the XML would be well formed.

I'm finding it difficult to understand the point you're making. Looking at the thread you suggested multiple documents in one file. I'm sorry I didn't take it seriously but it seemed to be a suggestion without practical application. If you wanted an xml representation of a log then the best ways to do that are either to build a service to accept log requests and then build an xml document at some point in the future or build a standard list file using something like log4j/log4net and the convert to an xml format using something like antlr.

As an aside I disagree that log file are by definition lists and not trees... that's just down to how you may have chosen to display them. You could easily create a very useful tree structure log which groups messages together by severity or some other criteria, store that in xml if desired and displayed in a very easy to use hierarchical display tree. You'd be able to easily achieve that with the suggestions I've put forward but not with a solution based on multiple documents.

Well off topic now though.

Edited by dern on Friday 2nd March 13:31

[Size Nine Elm]

<Reply>
<OriginalTopic>
You could indeed have an XML file with effectively multiple 'root' elements,
but you'd need to have multiple parses of the single file to get the multiple
documents out...
</OriginalTopic>
<EfficiencyDigression relevance="nil">
XML can be pretty verbose and large, but if you add compression it becomes really quite good.
</EfficiencyDigression>
<Edit>
To make the reply well-formed!
</Edit>
</Reply>

Edited by Size Nine Elm on Friday 2nd March 13:41

[ATG]

The _only_ point I was making it that there's no need for the boundaries of a file to be the boundaries of an XML document. You can have many XML documents in one file, one XML document spread over several files. The OP blurred the difference between the necessity of having "one root element per file" and "one root element per XML document". Nothing wrong with the former, whereas the latter is a no no.

[dern]

ATG said:

The _only_ point I was making

Yes, I know. If you don't want your post discussed further then simply say so. I was interested in the topic and mistakenly assumed you might be too.

Edited by dern on Friday 2nd March 13:53

[toni896]

I wasn't talking about a log file senerio,
It was a business message, Invoice,
Our translation expect 1 root element per physical file,

our supplier sent us a file is multiple root elements in a single file.
so the data we received looks like
<Invoice>Inv Data(hdr,body,vat etc .. )</Invoice>
<Invoice>Inv Data</Invoice>
<Invoice>Inv Data</Invoice>

What we expected is
<Message>
<Invoice>Inv Data</Invoice>
<Invoice>Inv Data</Invoice>
<Invoice>Inv Data</Invoice>
</message>

Now my question is aside from the fact the xml file does not match our xsd,
is the fact they sent multiple root elements in a single physical file correct, I understood is it not valid to do that.

[dern]

wikipedia said:

Document element

Every XML document must have exactly one top-level root element (alternatively called the document element), so the following would also be a malformed XML document: it has two top-level thing elements, with no overall parent element encasing them both.

<?xml version="1.0" encoding="UTF-8"?>
<!-- WRONG! NOT WELL-FORMED XML! -->
<thing>Thing one</thing>
<thing>Thing two</thing>

Hope this answers your question.