Topic: Export to XML (Read 5623 times)

nila · « **on:** April 30, 2003, 07:27:22 pm »

Hey

Just some questions about this feature.

I'm just learning XML now so I'm pretty new to it so forgive me if I am chatting rubbish.

With the XML method in MC, how come it exports all fields to xml fields called: field with a name attribute?
Why doesn't it just export them all to xml fields with the name of the field being the name of the field rather than to 'field' with the name as an attribute?

From what I've learnt so far, I can use css pretty easily to specify how to make the XML page look but I cant do this with the version of XML exported by MC as I cant specify how each field looks as each field is just called field and the css wont differentiate between them based on an attribute?

Points:

Why does MC export all fields to a field called 'field' with the name as an attribute instead of using it as the name of the field?
Is it possible to use CSS to design how this xml page appears the way it is currently with all fields being called simply field?
Couldn't we have an option on export to allow us to specify which way we'd prefer the XML to be written?
Also, couldn't we have an option on export to specify which fields we'd like exported and in which order?

sraymond · « **Reply #1 on:** April 30, 2003, 08:59:42 pm »

Nila,

I think your point makes a lot of sense. I use XMLSpy to work with XML content and it's got a nice "Stylesheet Designer" that works off of an XML Schema. The problem with MC's XML Export is that it only creates a document with three elements: MPL (the root), Item, and Field. That doesn't let me do much.

I agree that creating elements named with the field would be great! Of course, this would cause problems with custom fields because element (and attribute, for that matter) names must begin with a letter or "_" and the remaining letters can only contain letters, digits, "-", "_", or "."... and no spaces allowed. And, of course, some of the default field names would need to be changed as well.

You can see where this would cause some problems... but there are certainly solutions, such as fixing up the names to conform to XML. For example, "Date Created" would become "Date_Created".

The other solution is to do some java programming to transform the XML document created by MC to a format you'd prefer. It is a fairly simple effort (I'd guess less than 40 lines of code) to read in an XML document, perform some changes to the structure, and write it out to another XML document. Again, the hardest part would be in fixing the element names.

Scott-

NoCodeUK · « **Reply #2 on:** May 01, 2003, 04:35:33 am »

Nila,

You hneed to do a bit of research into XSLT. I too am currently learning XML and have found that XSLT is the most useful part of it so far. This allows you to transform an XML document into an HTML document. You create the XML file and XSLT file and then reference the XSLT file from the top of the XML file. When IE shows the file it shows it based on the rules within your XSLT file. It is basically like a programming language. You can say things like for each album in the list display name like this, date like this etc and it allows you to reference attributes easily too. Check out this url for more info:

http://www.vbxml.com/default.asp

It beats trying to use CSS hands down!!

Adam

sraymond · « **Reply #3 on:** May 01, 2003, 05:41:52 am »

Before you start doing XSLT creation by hand, take a look at XMLSpy's Stylesheet Designer (it comes packaged with their version 5 which is available as a thirty day demo I think)... I promise that once you do a transformation using it, you'll never want to do it the long way again!

NoCodeUK · « **Reply #4 on:** May 01, 2003, 06:12:43 am »

I may try that out. Although I have always been a die hard hand coder by heart...Its the only way to learn!!

Defo like the potential of XSLT and XML tho...

Adam

sraymond · « **Reply #5 on:** May 01, 2003, 09:30:17 am »

Quote

Why does MC export all fields to a field called 'field' with the name as an attribute instead of using it as the name of the field?

I've given this a little more thought - and assuming we're still talking about the same thing (making a tag named by MC's field name), I'd think there's also a non-compiled programming solution via XSLT (which is, after all, just another programming language - albeit declarative)

Though, I don't know how to save the results of a transformed (by XSLT) XML document to another XML document. Still, I would think that I could convert the attribute name value to an element tag easily enough - although I'm not sure how I'd go about cleaning up the name.

Scott-

P.S. JRiver: Why doesn't the exported XML have a declaration? I realize that it isn't strictly required, but I've always understood it to be good practice to include it.

nila · « **Reply #6 on:** May 01, 2003, 10:51:54 am »

hmm, I'm looking at XSLT right now and trying to work it out, as yet though I'm still not able to do much with it.
I can do stuff with the 'Field' nodes but cant do anything dependant on the attribute name yet.

Having the name as an attribute rather than as the entity is definitely making the coding a lot trickier

NoCodeUK · « **Reply #7 on:** May 01, 2003, 01:25:16 pm »

Nila,

Using the Xpath language I think you can access attributes byusing the @ sign so you would do something like Field/@Name to access the Name node. I am not sure of the exact syntax but I think that was mentioned in the tutorial I posted the link to.

Adam

sraymond · « **Reply #8 on:** May 01, 2003, 01:32:45 pm »

If you can't "convert" the field name until a valid XML element name, you're pretty much dead in the water.

I can't think of a way to use XSLT to parse attribute content (the field name) and get rid of the illegal characters. Does anyone have an idea?

I've been wanting to do some practice with JDOM - so maybe I'll try to write a program to do this. Of course, it would help if I were a java programmer!

Scott-

NoCodeUK · « **Reply #9 on:** May 01, 2003, 02:11:45 pm »

I will try and write an XSLT page that will transpose it and if I get it to work I will post it here

Adam

sraymond · « **Reply #10 on:** May 01, 2003, 04:39:43 pm »

Cool... but give me a hint: how will you make the element name legal?

Scott-

nila · « **Reply #11 on:** May 01, 2003, 06:00:46 pm »

Glad to see it's not just me thats finding it hard to use the XML in the method it's been done. It's definitely a LOT trickier than it needs to be

sraymond · « **Reply #12 on:** May 01, 2003, 07:25:40 pm »

Well, I didn't have the motivation to start programming with JDOM tonight to change the field attribute values to element names, but I did generate some XSLT that will display a table: the header is the name attribute value and rows are the field element content. Unfortunately, I'm not an expert with formatting tables, so the alignment isn't quite right. If someone can point out how to fix the spacing so that a table within a table allows for the columns to align, I'd appreciate it:

Scott-

MCLibrary.xslt:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xsl:template match="/">
<html>
<head/>
<body>
<xsl:for-each select="MPL">
<xsl:for-each select="Item">
<xsl:if test="position()=1">
<table border="1">
<thead>
<tr>
<td>
<xsl:for-each select="Field">
<xsl:if test="position()=1">
<table border="0">
<tbody>
<tr>
<xsl:for-each select="../Field">
<td >
<xsl:for-each select="@Name">
<input size="30">
<xsl:attribute name="value"><xsl:value-of select="." /></xsl:attribute>
</input>
</xsl:for-each>
</td>
</xsl:for-each>
</tr>
</tbody>
</table>
</xsl:if>
</xsl:for-each>
</td>
</tr>
</thead>
<tbody>
<xsl:for-each select="../Item">
<tr>
<td>
<xsl:for-each select="Field">
<input size="30">
<xsl:attribute name="value"><xsl:value-of select="." /></xsl:attribute>
</input>
</xsl:for-each>
</td>
</tr>
</xsl:for-each>
</tbody>
</table>
</xsl:if>
</xsl:for-each>
</xsl:for-each>
</body>
</html>
</xsl:template>
</xsl:stylesheet>

NoCodeUK · « **Reply #13 on:** May 02, 2003, 02:14:07 am »

Nice one Scott. I fiddled about for ages in XML Spy but couldn't seem to find anyway to display the separate elements...

Adam

nila · « **Reply #14 on:** May 02, 2003, 05:11:31 am »

Cool, I'm gonna have a play with this and see if I can fiddle it or what

salsbst1 · « **Reply #15 on:** May 02, 2003, 06:32:18 am »

Step One when you work with XML exported by MC9 is to fix the XML that has been exported so that it is VALID.

I do not understand why J River cannot make the XML valid. I pointed out the problem weeks ago. The last character of the document is an ASCII (or is it Unicode?) 0. This makes the document invalid, If they simply did not write that last character the document would be valid. Apparently standards compliance is not very high on the list. Sorry to sound whiny but I am not convinced that there is a good reason not to fix this, while there is every reason in the world to fix it. XML which is not valid cannot, in most cases, be parsed. Indeed, Internet Explorer 6 cannot parse the XML produced by MC9.

So, step 1: open the document in a text editor and delete the last character (it will look like a little hollow square in wordpad, for example).

salsbst1 · « **Reply #16 on:** May 02, 2003, 06:50:16 am »

sraymond, a strategically placed 'cellpadding="0" cellspacing="0"' can bring things back into alignment:

Code: [Select]


<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema"> 
 <xsl:template match="/"> 
  <html> 
   <head/> 
   <body> 
    <xsl:for-each select="MPL"> 
     <xsl:for-each select="Item"> 
      <xsl:if test="position()=1"> 
       <table border="1">
        <thead> 
         <tr> 
          <td> 
           <xsl:for-each select="Field"> 
            <xsl:if test="position()=1"> 
             <table cellpadding="0" cellspacing="0"> 
              <tbody> 
               <tr> 
                <xsl:for-each select="../Field"> 
                 <td> 
                  <xsl:for-each select="@Name"> 
                   <input size="30"> 
                    <xsl:attribute name="value"><xsl:value-of select="." /></xsl:attribute> 
                   </input> 
                  </xsl:for-each> 
                 </td> 
                </xsl:for-each> 
               </tr> 
              </tbody> 
             </table> 
            </xsl:if> 
           </xsl:for-each> 
          </td> 
         </tr> 
        </thead> 
        <tbody> 
         <xsl:for-each select="../Item"> 
          <tr> 
           <td> 
            <xsl:for-each select="Field"> 
             <input size="30"> 
              <xsl:attribute name="value"><xsl:value-of select="." /></xsl:attribute> 
             </input> 
            </xsl:for-each> 
           </td> 
          </tr> 
         </xsl:for-each> 
        </tbody> 
       </table> 
      </xsl:if> 
     </xsl:for-each> 
    </xsl:for-each> 
   </body> 
  </html> 
 </xsl:template> 
</xsl:stylesheet>

Regards,
Stuart

sraymond · « **Reply #17 on:** May 02, 2003, 02:41:56 pm »

Stuart,

Thanks! It works great.

Scott-

salsbst1 · « **Reply #18 on:** May 02, 2003, 04:09:17 pm »

It's peculiar that the cellpadding="0" cellspacing="0" is needed at all. Apparently IE decided, in its infinite wisdom, that tables embedded within TDs in a THEAD should get some padding and spacing. These inconsistencies drive me nuts!

Cmagic · « **Reply #19 on:** May 05, 2003, 12:08:13 am »

Hi,

Just a question to the XML gurus, is it normal that File|Library|Export to XML and File|Export Playlist (as an MPL for the whole library) give the exact same file with both a <MPL Version="2.0"> header ??
The only difference is the file extension, xml vs mpl.

For the xml file I was expecting some kind of "<?xml version="1.0" encoding="ISO-8859-1"?>" header.

Thanks

sraymond · « **Reply #20 on:** May 05, 2003, 07:57:39 am »

Cmagic,

I agree with you. I posted the following a week or so ago:

Quote

P.S. JRiver: Why doesn't the exported XML have a declaration? I realize that it isn't strictly required, but I've always understood it to be good practice to include it.

This is the technical name for the header.

Scott-

kcorbett · « **Reply #21 on:** May 05, 2003, 08:35:21 pm »

Quote

Step One when you work with XML exported by MC9 is to fix the XML that has been exported so that it is VALID. (...)

Removing that trailing byte is not sufficient to make the XML valid, but is a step toward making it well-formed (proper syntax).

I agree with Cmagic and sraymond, the output should have an XML declaration.

The XML may or may not be valid; I can't tell, because I don't have a DTD to validate it against. If validation is a goal, MC should probably emit a document type declaration. In that case the XML might look something like this:

Code: [Select]


<?xml version="1.0" encoding="ISO-8859-1" standalone="yes" ?>
<!DOCTYPE MPL PUBLIC "-//J River//DTD MPL 2.0//EN" "http://musicex.com/mediacenter/MPL.dtd">
<MPL Version="2.0">
...

[/pre]

/kmc

salsbst1 · « **Reply #22 on:** May 06, 2003, 07:47:14 am »

Quote

Removing that trailing byte is not sufficient to make the XML valid, but is a step toward making it well-formed (proper syntax).

I agree with Cmagic and sraymond, the output should have an XML declaration.

The XML may or may not be valid; I can't tell, because I don't have a DTD to validate it against. If validation is a goal, MC should probably emit a document type declaration. In that case the XML might look something like this:
Code: [Select]
<?xml version="1.0" encoding="ISO-8859-1" standalone="yes" ?> <!DOCTYPE MPL PUBLIC "-//J River//DTD MPL 2.0//EN" "http://musicex.com/mediacenter/MPL.dtd"> <MPL Version="2.0"> ...[/pre]

/kmc

Good point, I used the wrong term. Well-formedness (lack thereof) is the first problem to address. And I would be remiss if I didn't point out that schemae can also be used to validate an XML document. Maybe if we have a debate over DTDs and XSDs in this thread then eventually they'll delete the bad character.

Nikolay · « **Reply #23 on:** May 06, 2003, 11:35:11 am »

Hi everybody,

I would never guess that XML files generated by MC would be an object of such a thorough scrutiny by our community

We added ability to generate the files so external applications can get access to information stored in Media Centers library. We never expected it to be edited by XML editor.

Anyway, next build will remove 0 at the end of XML files and add XML declaration.

The reason we use generic word "Field" instead of actual field name is that field names can be in Chinese and as you all know XML tag names are not very flexible.

Nikolay

salsbst1 · « **Reply #24 on:** May 06, 2003, 12:10:59 pm »

Quote

Hi everybody,

I would never guess that XML files generated by MC would be an object of such a thorough scrutiny by our community

We added ability to generate the files so external applications can get access to information stored in Media Centers library. We never expected it to be edited by XML editor.

Anyway, next build will remove 0 at the end of XML files and add XML declaration.

The reason we use generic word "Field" instead of actual field name is that field names can be in Chinese and as you all know XML tag names are not very flexible.

Nikolay

Thanks for the removal of the 0. External tools that need well-formed XML will appreciate the change, too!

Regards,
Stuart

nila · « **Reply #25 on:** May 07, 2003, 09:30:40 am »

Nickolay,
The logic behind the decision makes perfect sense to give MC the ultimate flexibility.
The majority of users however probably wont be doing chinese or anything else too wierd however and the other method would make our lives a lot easier.
Obviously you wouldn't want to rule out the people who would want it though and so would it be possible to make it optional which way it was exported?
It would make the xml feature a lot simpler to use and give us a lot more flexibility with it.
If people needed the extra ability of doing it the field way they could. For those of us with more simple needs the xml would be way easier to control.

Pretty please?

Nikolay · « **Reply #26 on:** May 07, 2003, 09:33:28 am »

Sorry, Nila. Not in this version.

Nikolay

salsbst1 · « **Reply #27 on:** May 07, 2003, 10:56:42 am »

Quote

Nickolay,
The logic behind the decision makes perfect sense to give MC the ultimate flexibility.
The majority of users however probably wont be doing chinese or anything else too wierd however and the other method would make our lives a lot easier.
Obviously you wouldn't want to rule out the people who would want it though and so would it be possible to make it optional which way it was exported?
It would make the xml feature a lot simpler to use and give us a lot more flexibility with it.
If people needed the extra ability of doing it the field way they could. For those of us with more simple needs the xml would be way easier to control.

Pretty please?

Nila, I think J River's existing XML is about the way it should be. I don't think tools should change schemae with such regularity as MC would if field names became part of the XML schema. That said, I can appreciate that you want such a format for your own purposes. The following XSLT sort-of gets you there. IT is not, in its present form, useful for very much.

As has been mentioned, XML has some rules. These include that the following may not appear in element and attribute names:

#
"
(that's a space btw)

This XSLT works on a really short demo library that lives on my laptop. This is a quick-and-dirty version. Better escaping of illegal characters is obviously possible. But I think it's a wild goose chase. In this application, I think field name meta-data does not belong in the schema. Think of how difficult it would to write a tool that generically handles the XML files that MC would generate.

Code: [Select]


<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema">
      <xsl:template match="/">
            <custom-MPL>
                  <xsl:for-each select="MPL">
                        <xsl:for-each select="Item">
                              <xsl:element name="Item">
                                    <xsl:for-each select="Field">
                                          <xsl:variable name="elname">
                                                <xsl:value-of select="translate(translate(@Name,' ',''),'#','')" />
                                          </xsl:variable>
                                          <xsl:attribute name="{$elname}">
                                                <xsl:value-of select="." />
                                          </xsl:attribute>
                                    </xsl:for-each>
                              </xsl:element>
                        </xsl:for-each>
                  </xsl:for-each>
            </custom-MPL>
      </xsl:template>
</xsl:stylesheet>

Regards,
Stuart

kcorbett · « **Reply #28 on:** May 07, 2003, 03:35:09 pm »

Quote

Maybe if we have a debate over DTDs and XSDs in this thread then eventually they'll delete the bad character.

Bring it on! (just kidding :)

NoCodeUK · « **Reply #29 on:** May 07, 2003, 03:44:02 pm »

Stuart,

Your XSL file looks great ... however one of my fields contains a /which needs to be transcoded. Howwould I add in a statement to transcode this as well as the other symbols eg #

Cheers

Adam

INTERACT FORUM

Author Topic: Export to XML (Read 5623 times)

nila

sraymond

sraymond

sraymond

nila

sraymond

sraymond

nila

sraymond

nila

sraymond

sraymond

nila