There is no schema that tells you the order of the elements, so your loaded must deal with the data in any order. I see no reason to apply a rigid XML schema just to define an order that happens to fit one users current implementation.

Well, I have a hard time defending this request, because to me, our software isn't working right. But that's what the author/supporter told me to say. To me, I'd have thought we'd parse the entire <DVD> item, then start spitting out records but I'm told it's a sequential engine that starts spitting out records when it comes to the table-path items.

I'm trying to create a table with the following fields: Id, Title, SortTitle, and ChildId, where ChildId is the Content tag. There is one record per ChildId. So that's why I need the SortTitle along with the BoxSet Content.

So, even though I can't come up with any strong reasons to change this, I'm hoping it's such a trivial change that Ken'll just do it. After all, it was working this way in 2.4 without hurting anyone.

The mentioned author/supporter should maybe consider fixing his XML reader instead of requesting other people to adjust standard XML formats to suit his broken reader. Simply declaring the arbitrary subset of XML he supports "good hierarchical design" doesn't make it so.

If he is not willing to fix it, you really should consider learning XSLT - it is not that hard (it just looks verbose due to the XML syntax) and it can move items around extremely easily. Yes, a learning curve is involved, but it can be useful over time as you can relatively easily convert XML files between varous formats.

Quoting m1duckett:

Quote:
Quoting lmoelleb:

Quote:
There is no schema that tells you the order of the elements, so your loaded must deal with the data in any order. I see no reason to apply a rigid XML schema just to define an order that happens to fit one users current implementation.

If the XML comes out in any order, this is not XML standards compliant, minimally there should exist a DTD and optimally an XML schema.

Incorrect.
1) DTD's are optional (and practically though not officially depricated). Schemas are optional  (a good idea to have one for sure, but it is NOT a requirement to be XML standards compliant).
2) Neither a DTD nor a Schema would nesessarely mean the order of the elements where fixed

Quote:

The DTD or schema is an interface contract that downstream software would need to follow in order to integrate cleanly with the export.

Correct and obvious. However without the schema present you have to assume the worst as noone has promised you anything better, and the worst is elements in any order.

Quoting FredLooks:

Quote:
The order of the credits is, as we all know, extremely important, and the only manner in which this is encoded is positional within the XML file. This is strikingly obvious if you consider credits with dividers.

I'm not sure what your problem is with that. The order of elements is preserved if you load an XML file. It is also preserved through XSLT transformations., Even if you force a different order via <xsl:sort> that would only affect your output, the input of elements still happens in original order.

Of course, if you create database records from the XML, you have to add an Order or LineNo field, or an AutoInc key, but that is nothing unusual.

Quoting FredLooks:

Quote:

... The order of the credits is, as we all know, extremely important, and the only manner in which this is encoded is positional within the XML file. This is strikingly obvious if you consider credits with dividers.

Just a FYI - this is referred to as "document order". Makes it a bit easier to discuss when we use the same terms.

Goodguy gave you some options to keep the order in the DB - personally I tend to use a simple index. Character or byte position into the XML document will do as well, but line number alone won't work as a change to the insignificant whitespaces alone (which per definition does not change the content of the XML file) could result in multiple actors on the same line.

Quoting FredLooks:

Quote:

...
And I used the term "linenumber" rather imprecisely, sorry. I actually store a number which represents the ordinality of the <Actor> term within the current <Actors> container. I just called it a linenumber so I'd remember the name It's really just an index ...

"Interesting" naming convention... 

NB: the original poster is wrong to expect the element order to change.

I am arguing the necessity of having the schema.

Quoting lmoelleb:

Quote:

Quoting lmoelleb:

2) Neither a DTD nor a Schema would nesessarely mean the order of the elements where fixed

Ambiguous data structures are poor programming practice.

Quote:
However without the schema present you have to assume the worst as noone has promised you anything better, and the worst is elements in any order.

Any non-trival XML document will have semantic meaning to the structure of the data.  To make meaningful sense of random ordering, one would need to add an order of complexity to the implementation.  This would be a maintenance nightmare.

It is poor practice not to provide the data definitions to your clients.  DVD Profiler 2.4 provided an XML schema, I am not sure why one can not be provided for 3.0.  There certainly no trade secrets exposed by it.

NB: I understand there is no order guaranteed with elements of the same name.