Is it just me or is that poor XML structure? And I think there are problems with it. I have a 2 playlist nodes in a row then I have the tune nodes for 1 of the playlists then the tune nodes for the other playlist.

Although I work with XML and XSL/T every day I do not consider myself an expert or an architect so maybe there is some reason this came out this way.

But it seems to me that it should be more like this
PLAYLISTS
PLAYLIST/ (how ever many there are of these)
/PLAYLISTS
TUNES
TUNE/ (again however many there are but also add a parent node that points to the playlist FID that it belongs to)
/TUNES

Just my thoughts on it. I did not put the LT and GT brackets around them as they get swallowed.

XML? How did I miss this? Where does XML get used?

We can now export our playlists as XML as well as CSV (which we already had) .

Whatever menu has the Export on it... Under Tools I think (can not check it as Emplode locks up here at work)...This is 2.0b7 .... you could always export to CSV but I wanted to try the XML.

Hey that's pretty cool. Any possibilty of IMPORT of playlists? Probably not useful since you have to know the Song ID number of each tune to create the playlists..

Exactly. Only for export. It is nice cause now I can export my list and then use XSL to transform/display it in any format that I want..Maybe I will write an XSL to do a simple list and post it here...EDIT: Although import may be possible...for instance if you wanted to resturcture the playlists....maybe it would have to wipe out what was there and build it based on your XML...You could not create new playlists but maybe move/copy tunes/playlists to be under other playlists. That would be a function of Emplode to read it in and redo the structure.

Most definitely if you write and XSL transformation script you should share it with us...That would be very cool...

I am next to positive that either Roger or Rob (I'm leaning toward Roger) have mentioned that emplode will feature a database importing feature down the road.

Bruno

I haven't seen the xml export yet, but if that's the format, it's not well-formed xml as an xml document is only to have one root element. It appears there are two there. Maybe what it really needs is a root element containing what is already exported. Like this:

empeg
playlists
playlist/
playlist/
/playlists
tunes
tune/
tune/
/tunes
/empeg

Chris

The Xml output from the 2.0B7 version of emplode is well formed XML.
You can display it properly in IE 5+ - always a good initial test of a XML document for well-formed-ness.

The node structure is basically as follows:
[I've used square brackets for angle brackets in this post]

[nodestore player_name="name of my empeg"]

  [playlist fid="xxx"]

    [children]

        [child]nnn[/child]

    [/children]

     ...

    ]/playlist]

    ...

  [tune fid="yyy"]

      ...

  [/tune]

  ...

[/nodestore]

so the XML is using attributes as well as elements [perfectly ok in XML].

Playlists appear first, especially the 2 'reserved' playlist of all playlists and of unattached items.
Then the tune nodes for the playlists then the next playlist node etc.
Note: A tune can be in more than playlist thats why tunes are not nested under the playlist node. But instead a reference to the tunes FID is nested under the playlist. The Tune proper is output following the first playlist where it is referenced.
However the children node contains a list of child nodes with the fid for each tune in the playlist, so you can create a tree with tune information nested under the playlist if desired.

Yes, I know it is well-formed per XML standards. I merely meant to say it was not very human-readable friendly which makes it look wrong to me. It seemed to output playlist and tune nodes at random intervals. I was suggesting it groups the playlist nodes under a playlists node and the tune nodes under a tunes node. XML is very free flowing as long as you have start and end tags in the right place but that does not mean the result is a good structure. And since TUNE can belong to more than 1 PLAYLIST, then make a PARENTS node that contain PARENT nodes for each playlist it belongs to. I just think that would make it much easier to use through XSLT.

When making my structure I did not bother putting a root element to encase the PLAYLISTS and TUNES nodes. Just laziness on my part.

I think that this structure reflects actual way data is stored in empeg. PARENTS tags would have to be calculated by crossreferencing. This way they just traverse the tree (taking care to output a particular list or tune node just once - after it has been first referenced).

It's difficult to make playlist structure dump human-friendly without repeating list or tune data - FID reference means little to human reader. Can be done, I think, with a bit of redundancy. But then, human-readability is just secondary property of XML - the main being ease of parsing and certain self-documentation.

How about this redundant, but human-readable and parsable format?

[nodestore player_name="name of my empeg"]

   [tree]

      [child type="P" FID="100" title="empeg"]

         [child type="P" FID="yyyy" title="abc"]

            [child type="T" FID="zzzz" title="bac" /]

            [child type="T" FID="aaaa" title="bca" /]

            [child type="T" FID="bbbb" title="cba" /]

         [/child]

         [child type="P" FID="WWWW" title="def"]

            [child type="T" FID="zozo" title="123" /]

            [child type="T" FID="aaaa" title="bca" /]

            [child type="T" FID="roro" title="456" /]

         [/child]

         [child type="P" FID="xxxx" title="qwe"]

            ....

         [/child]

         ....

      [/child]

   [/tree]

   [nodes]

      [node type="P" FID="100" title="empeg"]

      [node type="P" FID="xxxx" title="ttt"]

         [parents]

            [parent FID="100" title="empeg" /]

         [/parents]

         [tags]

            [tag type="title"]ttt[/tag]

            [tag type="source"]sssss[/tag]

            .....

         [/tags]

      [/node]

      [node type="P" FID="yyyy" title="abc"]

         .....

      [/node]

      [node type="T" FID="aaaa" title="bca"]

         [parents]

            [parent FID="yyyy" title="abc" /]

            [parent FID="wwww" title="def" /]

         [/parents]

         [tags]

            ......

         [/tags]

      [/node]

      [node type="T" FID="bbbb" title="cba"]

         .....

      [/node]

      [node type="T" FID="roro" title="456"]

         .....

      [/node]

      [node type="T" FID="zozo" title="123"]

         .....

      [/node]

      [node type="T" FID="zzzz" title="bac"]

         .....

      [/node]

   [/nodes]

[/nodestore]

First comes the complete tree (with repeated child nodes as needed - one child node per one FID mentioned in a playlist) and titles added for readability (identification is by FIDs, of course), followed by nodes (both lists and tunes) and their empeg-tag data (title, artist...). Parent tags are redundant, but come handy to human readers.

1. It's well-formed XML
2. It's in arbitrary order. Generally, this would be by FID.
3. Outputing the 'parent' entries is far too complicated.
4. It only took 5 minutes to write - give me a break.

Now you're on the right track!

Those redundancies can be refactored as well, actually. (Definitely don't want duplicate info.)

I'll have a look-see today and see ...

Roger - kudos for writing this, make no mistake!

Call it unbridled enthusiasm, I guess.

Thanks for putting it in there Roger.

Personally I don't much care if its the desired format of XML or not - since its XML we can map it using XSLT to *any* XML variant we like.
[And that is the whole point of XML - you don't need to get it in the final format - just output it as well formed XML and do a XSLT transform to make it have the right format].

Getting the playlist file into the correct XML from a CSV file would take a lot more [programming] effort by us than writing a XSLT to convert the current version of XML to a 'nicer' one.

So, a big thanks for putting XML support in there at all Roger.

O-Kay ... I went and did a closer (read: proper) comparison. And ...

About my only concern with the current XML output really concerns the choice of using CDATA vs. Attributes in various spots. However, that very topic can pretty much devolve into something close to religious debate, so I might want to steer clear of that one!

Other than that, the XML is well-formed, and non-redundant ... and completely machine-readable. This is A Good Thing^tm.

Having written that, and knowing full well the wonders of XSLT, I'm curious to know what kinds of transformations folks are seeking (if at all). Perhaps we can kick-start a collection for riocar.org or something. Suggestions welcome!

(Roger, thanks again - that you pulled this off in five minutes is in fact most laudable.)

since its XML we can map it using XSLT to *any* XML variant we like
Sure...if you know XSL. The thing about the export, for me, was that I could use it to quickly look up what I have on my EMPEG, see what I am missing, what I still need to rip, etc. CSV works great for this as I can put it into excel and sort it anyway which way. With the XML, though, I can not even look and see what tunes go with what playlist without knowing the fid, etc.

I know this is a dump of the data and done in 5 minutes. I am just voicing my opinions here. Maybe everyone who owns an EMPEG can write an XSLT file without a problem. Then again, I doubt this. At least with a cleaner format, those people would be able to open the XML in IE and have an easier time. Then they can send it to friends and say hey here is my collection just open in IE, etc.

Thanks for listening to me ramble...

Do you have a document that describes each node/attribute? I'd be interested in seeing it, if you do. I know most are self explanatory but, like, what is the length attribute for playlist?

Thanks.

If people come up with groovy XSLT files and send them to me, I'll package them up as templates, and add an option to the export dialog so that the XML file header references them.

This'll cause IE to render one with the other. Then, you will be able to give them to other people to look at.

If, on the other hand, having attempted to write some XSL, people are having difficulty because of the XML format, let me know. I'll see what I can do to clean it up a little. I could, I suppose, stop using the CDATA bits, if that's an issue.

It's not meant to be human-readable, though.

It's the number of bytes used to store the child FIDs. It's transcribed directly from the *1 file. See if you can find any information about those -- it should answer these questions.

Do you have a document...

No.

Have you tried importing the XML file into Excel 2002 (the version of Excel that ships with Office XP)?

If you do, you may be pleasantly surprised in terms of how much more functional a XML document is within XL 2002 even without any XSL files as compared to a CSV file.

You are right that not many of us here can probably eat,drink and write XSL files, but then the same could well be said to apply to a proprietary Binary format that Roger could equally have knocked up in the 5 minutes he spent on the XML export feature.

I did not notice that there were CDATA sections in the XML document, which given Rogers time constraints is understandable.
However you are right for full capablilities you do need to minimise the use CDATA sections as much as you can as the information in CDATA sections is not easily broken out without custom programming.

re: Nice view of the Playlist, if you have a suggested structure of your playlists that you would like to see in IE, then I will atempt to create a XSLT that will produce the indicated web page from the XML file exported from emplode [in HTML suitable for IE].

But you will need to give me a mock up of what it is you want to see as everyones idea of a good playlist page will be different.

If there is data in the CDATA sections you want included, let me know this and I will extract the relevant bits as well.

I did not notice that there were CDATA sections in the XML document

Whoops ... that might have been my bad, as I had brought up a CDATA concern (not major though).

My understanding is that Character Data (or perhaps Parsed Character Data) would necessraily be the text in between the tag start-and-end pair, or CDATA as an attribute value, natch.

But, yes, it's true, no explicit CDATA sections! Not needed anyway, IMHO.

I had not yet kicked around the XML handling in Excel (too busy with XML Spy and all that). Nice! Thanks for that pointer.

Hmm. Y'think folks would appreciate someone whipping up an XML Schema to match what Roger has done? Or is it unnecessary? (If it's wanted, yes, Joe silently raises his hand to do the deed.)