Topic: REQ: Improved XML Export (Read 5369 times)

NoCodeUK · « **on:** October 07, 2003, 04:17:10 pm »

I know this is too late now for 9.1 but hopefully for next version. Scott has written a fantastic XSLT that will convert the Media Library into an HTML catalogue. It looks great but there are a couple of issues at the moment. You can either export as an MPL file or export the library as XML. Here are the issues though. MPL is great as it allows you to select what you export but the disadvantage is it does not export calculated fields. XML exports calculated fields but only exports the whole library (which crashes the XSLT) so...any chance of a compromise? An XML export facility that allows you to select what to export or MPL with the ability to export calculated fields?

Cheers

Adam

NB: The reason the calculated field export is necessary is to show the cover art when it is stored in the media folder. With calced fields I can show Filename(path)/Image name. Without this I can only show image name which gives folder.jpg

NoCodeUK · « **Reply #1 on:** October 07, 2003, 04:20:12 pm »

Was also wondering what order the XML export is in. It seems to be the same everytime but I cannot understand where the order comes from. It starts with an artist beginning with M and an album beginning with E??

Cheers

Adam

sraymond · « **Reply #2 on:** October 07, 2003, 06:32:17 pm »

I mentioned this elsewhere, but to keep this thread complete:

- Please put the <Field> element content in a CDATA section. This ensures the XML is well-formed by not parsing MC field content.

I realize this breaks the cleanliness of the MPL, so maybe a fourth Export Playlist option (XML) is better.

Scott-

sraymond · « **Reply #3 on:** October 10, 2003, 03:33:56 pm »

Bump.

TimB · « **Reply #4 on:** October 10, 2003, 07:58:23 pm »

Bump

-=Tim=-

NoCodeUK · « **Reply #5 on:** October 13, 2003, 05:06:57 am »

Oooh Watch out for that - BUMP!!

Adam

sraymond · « **Reply #6 on:** October 17, 2003, 08:13:33 pm »

Quote from: sraymond on October 07, 2003, 06:32:17 pm

- Please put the <Field> element content in a CDATA section. This ensures the XML is well-formed by not parsing MC field content.

Bump.

I'm working on some *very* large XML exports (100+ MB - more than XSLT does gracefully) and I'm up against some invalid XML characters. Unfortunately, the document is too big for XMLSpy or Stylus Studio to open - so I can't easily see where the problem is to fix.

Scott-

graham131 · « **Reply #7 on:** October 18, 2003, 06:06:38 am »

Quote from: sraymond on October 17, 2003, 08:13:33 pm

Quote from: sraymond on October 07, 2003, 06:32:17 pm
- Please put the <Field> element content in a CDATA section. This ensures the XML is well-formed by not parsing MC field content.

Bump.

I'm working on some *very* large XML exports (100+ MB - more than XSLT does gracefully) and I'm up against some invalid XML characters. Unfortunately, the document is too big for XMLSpy or Stylus Studio to open - so I can't easily see where the problem is to fix.

Scott-

Bump.....

Scott is working on 1 of my files (105Mb - approx 68000 tracks). Would love to be able to use it.

Graham

sraymond · « **Reply #8 on:** October 21, 2003, 04:45:57 pm »

So maybe I *am* going crazy. Doing some recent tests with the Export Playlist (MPL Format), it seems that the entity references (&, <, >, ', ") are being escaped properly - meaning there's no need for CDATA sections. Indeed, as they occur so infrequently, it's a lot more efficient to escape the few occurences rather than always using a CDATA section.

I did have some trouble with Graham's *huge* file being encoded as Windows-1252 (vice UTF-8), but maybe that was an anomoly (perhaps the file was edited and saved using the wrong encoding).

So... it might be that the the Export Playlist (MPL Format) is working exactly as it should be. Am I going crazy, or were some changes made recently?

It would be nice to be able to choose the fields to export (like HTML and ASCII delimited) - including calculated fields. Please?

Scott-

sraymond · « **Reply #9 on:** October 28, 2003, 01:48:56 pm »

Quote

It would be nice to be able to choose the fields to export (like HTML and ASCII delimited) - including calculated fields. Please?

Bump.

nila · « **Reply #10 on:** October 29, 2003, 02:57:26 am »

It'd probably be fairly easy to make an export plugin although it definitely wouldn't be anywhere near as fast as MC doing it.

Could be the answer thou?

hit_ny · « **Reply #11 on:** October 29, 2003, 04:48:58 am »

i am trying to import the library xml into access so i can get some graphs drawn..

is there a way to parse the xml in the state it is currnetly so access can make some sense of it.

or do i need to use some xsl ?

hit_ny · « **Reply #12 on:** October 29, 2003, 08:12:41 am »

i found stuarts XSL, this gives me a HTML page

again i am looking for a way to import and actually use MCs data

any ideas anyone ?

sraymond · « **Reply #13 on:** October 29, 2003, 08:24:57 am »

Quote from: hit_ny on October 29, 2003, 04:48:58 am

i am trying to import the library xml into access so i can get some graphs drawn..

is there a way to parse the xml in the state it is currnetly so access can make some sense of it.

or do i need to use some xsl ?

What database schema are you looking for? If you're looking for something quick and easy, you might find that ASCII delimited works better.

Scott-

hit_ny · « **Reply #14 on:** October 29, 2003, 09:00:35 am »

Quote

If you're looking for something quick and easy, you might find that ASCII delimited works better.

yep, thats what i am starting to think as well. All this XML hype is not amounting to much use for me since no DTD is provided.

How do i get ascii delimted from MC or from the XML.

The schema wil be very simple basically just 1 table and all the fields in it as columns. i might want to skip on path since that's not very useful.

i wanted to be able to graph stuff like (pie or bar-graphs)

-what % do diff genres make-up out of all genres.

- what genres do tracks rated 3 and above fall into and the % spread.

- % of different encoding rates.

- not sure if this can be done with smartlists or not in which case i would use access.

i rate tracks, and to get an over all score for an album i avg the ratings. i was going to make a query that allows me to see avg scores in decimal increments of 0.1 between 2 and 4

wonder if there is an easier way to achieve this ?

sraymond · « **Reply #15 on:** October 29, 2003, 02:39:20 pm »

Quote

yep, thats what i am starting to think as well. All this XML hype is not amounting to much use for me since no DTD is provided.

Well, I think that's a bit of an exaggeration. If it'd make you feel any better, I'll give you a DTD or Schema for the schema - but as schemas go, you can't get much simpler than the MPL format.

Most everything you've asked for could be done with XML - but you'd have to question the benefit of doing it that way. Access is certainly a good alternative. Even better would be an ability to query the MC database directly from Access - but I don't imagine that would happen too soon.

Scott-

scott_r · « **Reply #16 on:** October 29, 2003, 10:31:45 pm »

Quote from: Nila on October 29, 2003, 02:57:26 am

It'd probably be fairly easy to make an export plugin although it definitely wouldn't be anywhere near as fast as MC doing it.

Could be the answer thou?

Which is exactly what I'm working on at the moment. It uses the .NET XML framework to create compliant XML documents, which makes it easy to output a database with weird characters in it. Problem is .NET is being annoying when it comes to registering it for COM, so it's proving difficult to package up for other people to use, but I think I've got it figured out.
Here's a screenshot:
http://homepages.paradise.net.nz/~scottray/images/xmlexportshot.jpg

Let me know whether this is what you want.

Scott.

sraymond · « **Reply #17 on:** October 30, 2003, 12:03:18 am »

Quote from: scott_r on October 29, 2003, 10:31:45 pm

Quote from: Nila on October 29, 2003, 02:57:26 am
It'd probably be fairly easy to make an export plugin although it definitely wouldn't be anywhere near as fast as MC doing it.

Could be the answer thou?

Which is exactly what I'm working on at the moment. It uses the .NET XML framework to create compliant XML documents, which makes it easy to output a database with weird characters in it. Problem is .NET is being annoying when it comes to registering it for COM, so it's proving difficult to package up for other people to use, but I think I've got it figured out.
Here's a screenshot:
http://homepages.paradise.net.nz/~scottray/images/xmlexportshot.jpg

Let me know whether this is what you want.

Scott.

Scott.,

I hope preparations for November's exams are going well...

Awesome! This would do the trick perfectly. If I might make one request, could it be possible to launch the .xml (either internal to MC or in an external browser window) automatically?

I couldn't tell from the screenshot - does this export all the fields (especially calculated)? I also assume that the XML conforms to the MPL schema.

I can't wait to try this out. Thanks again!

Scott-

scott_r · « **Reply #18 on:** October 30, 2003, 12:08:00 am »

I'm just working on getting calculated fields working. So far you can select which standard database fields to export. And it wont be a problem to launch the XML file once it's been generated - I'll add some options for that soon.

Scott.

EDIT: Yeah, forgot to mention that it conforms to MPL.

nila · « **Reply #19 on:** October 30, 2003, 04:55:25 am »

Couple of points (questions)

Unless your plugin can actually work out what fields are in MC then u should allow people to add aditional fields so they can add fields they've created in MC themselves.

Also - could this be extended to just allow us to use it for exporting to a text file where we can specify the delimiter?

What'd be GREAT would be if you could set it up to Export to SQL too
(just output each file as:

INSERT INTO [give us a table name input] (list all the field names seperated by comma's) VALUES (all field values - properly escaped);
)

ie. Make it an Output plugin rather than just an XML output.

NoCodeUK · « **Reply #20 on:** October 30, 2003, 05:40:15 am »

Scott that looks absolutely awesome...what is it about people called Scott R and excellence in XML

I wait for this with bated breath....Thank you!!

Adam

scott_r · « **Reply #21 on:** October 30, 2003, 09:08:16 am »

Hey guys, just posted over on the Plug-ins board:
http://yabb.jriver.com/interact/index.php?board=5;action=display;threadid=16462

Nila, your idea sounds totally excellent - hadn't even thought of using it for SQL. I'll certainly look into that, but just from thinking about it, that's going to be one HUGE SQL statement

Don't know how Windows would like passing that around.

Lets just see if what I've got so far is what you're all looking for - if so I'll get to work on expanding it some more.

Cheers,

Scott.

JimH · « **Reply #22 on:** October 30, 2003, 09:29:34 am »

And now for something completely different. Scott's link to megatokyo.com leads to a bio for him and to the site he helped found called thinkgeek.com. Here's how far out thinkgeek is:

http://www.thinkgeek.com/gadgets/watches/5eec/

Nice work, Scott. Thanks.

scott_r · « **Reply #23 on:** October 30, 2003, 09:34:33 am »

Cant wait for the 2GB version.

Scott.

edit: and just so we're clear, I've got nothing to do with megatokyo.com - it's just a great site that I visit.

nila · « **Reply #24 on:** October 30, 2003, 10:31:41 am »

Yeah, I've been thinking about SQL for a while - to me it's important if I'm gonna get into using MC properly for images as I'm going to want to keep my and my dynamic photo website syncronised.

SQL export is basic - just put each insert statement on a new line - not too big a deal - win should be able to handle that.
The more tricky bit is going to be the SQL import.

Also - I want to somehow get it to do 'Update' functions rather than just 'INSERT' functions - thats when it's gonna get trickier - I'm probably gonna make a plugin JUST for that to begin with - then later it's going to get merged into website creator so it can do Dynamic sites - it's gonna be tricky!!

sraymond · « **Reply #25 on:** October 30, 2003, 02:00:21 pm »

Quote from: Nila on October 30, 2003, 04:55:25 am

Couple of points (questions)

Unless your plugin can actually work out what fields are in MC then u should allow people to add aditional fields so they can add fields they've created in MC themselves.

Also - could this be extended to just allow us to use it for exporting to a text file where we can specify the delimiter?

What'd be GREAT would be if you could set it up to Export to SQL too
(just output each file as:

INSERT INTO [give us a table name input] (list all the field names seperated by comma's) VALUES (all field values - properly escaped);
)

ie. Make it an Output plugin rather than just an XML output.

Nila,

I think the most flexible way of approaching what you're talking about it to just use an XSLT to transform the MPL into any other "format". This is, after all, one of the prime "powers" of XML. Why "lock yourself" into a specific plugin format (other than XML!)?

I'm passingly familiar with SQL - but if you have an actual example (that works, of course), I'll write you an XSLT that converts the result of Scott.'s export to a text file.

The same idea applies to converting the MPL into a text delimited file - why do it in the plugin when you can just apply an XSLT that does it for you?

Scott.: Perhaps you'd consider adding a function to your plugin that lets the user apply an XSLT and save the resultant file as a text document. So there'd be two options: 1) Add an XSLT style-sheet reference to the export and open the XML in Explorer (which you've already done!) and 2) Choose an XSLT, transofrm the XML with it, and save the result as a text document.

I don't imagine it'd be too hard to code the plugin to apply the transformation.... you can see how easy it was in JavaScript by looking at XAlbum.htm.

Scott-

P.S. You're plugin works great for me - though it's pointed out a problem I had with xsl:key's and empty fields. I also think I've made a mistake in the multi-level grouping when two different albums have the same name (but different artist, of course!)

hit_ny · « **Reply #26 on:** October 30, 2003, 02:19:39 pm »

Quote

If it'd make you feel any better, I'll give you a DTD or Schema for the schema - but as schemas go, you can't get much simpler than the MPL format.

Yes pls, access accepts DTDs. It would be interesting to see how far one can go with the XML dump given a DTD.

sraymond · « **Reply #27 on:** October 30, 2003, 03:13:02 pm »

Quote

Yes pls, access accepts DTDs. It would be interesting to see how far one can go with the XML dump given a DTD.

Can you give me an example of how you'd find the DTD useful?

Scott-

RobOK · « **Reply #28 on:** October 30, 2003, 05:00:22 pm »

Quote from: JimH on October 30, 2003, 09:29:34 am

And now for something completely different. Scott's link to megatokyo.com leads to a bio for him and to the site he helped found called thinkgeek.com. Here's how far out thinkgeek is:

http://www.thinkgeek.com/gadgets/watches/5eec/

Nice work, Scott. Thanks.

ThinkGeek ROCKS!!!!!!!

Caffeine products, RC mini cars, all sorts of T-shirts (perhaps a Media Center t-shirt needs to be made), and best of all Fridgits.

http://www.thinkgeek.com/cubegoodies/toys/3627/

I dont know Scott, but I highly endorse ThinkGeek for all your shopping needs!

R.

hit_ny · « **Reply #29 on:** October 31, 2003, 02:27:03 am »

Quote

Can you give me an example of how you'd find the DTD useful?

i would import it into access after the library xml, i'm hoping access will be able to make more sense of the library XML.

Currently it only shows ITEM after import.

i would expect one table with all the attributes displayed as columns. i think once this is done, if any further tables need to be created, it wont be too difficult to do so within access itself.

Given this display i am hoping to be able to graph, certain columns as explained in an earlier post.

I am curious to know what applications ppl have made of the library xml to date. My intention is to show data that currently MC is not capapble of handling.

My idea to use access was to cut down on any coding reqd, simple, quick and easy. In fact the choice of access was because i was unable to find any other application that could take a XML input and be able to produce graphs. If there are any other apps u know of that can do this...do let me know.

Thanks

nila · « **Reply #30 on:** October 31, 2003, 06:08:18 am »

Well in that case - as a request for the plugin - allow it to load up and save XSLT's so that we can have saved ones for: Export to comma delimited, export to SQL etc.

For sql it would just need to be outputted like this:

INSERT INTO 'tablename' (`fieldname1`, `fieldname2`, `etc`) VALUES ('value1', 'value2', 'value3')

repeated for each file - so for ten files u'd have ten lines repeating that.

Pretty straight forwards old SQL is

RobOK · « **Reply #31 on:** October 31, 2003, 06:48:40 am »

Quote from: hit_ny on October 31, 2003, 02:27:03 am

Quote
Can you give me an example of how you'd find the DTD useful?

i would import it into access after the library xml, i'm hoping access will be able to make more sense of the library XML.

Currently it only shows ITEM after import.

i would expect one table with all the attributes displayed as columns. i think once this is done, if any further tables need to be created, it wont be too difficult to do so within access itself.

Given this display i am hoping to be able to graph, certain columns as explained in an earlier post.

I am curious to know what applications ppl have made of the library xml to date. My intention is to show data that currently MC is not capapble of handling.

My idea to use access was to cut down on any coding reqd, simple, quick and easy. In fact the choice of access was because i was unable to find any other application that could take a XML input and be able to produce graphs. If there are any other apps u know of that can do this...do let me know.

Thanks

I believe Excel can do that, I have seen it take XML, but not sure about what version of Excel. Not sure about OpenOffice.org, but might be worth trying.

sraymond · « **Reply #32 on:** October 31, 2003, 10:23:45 am »

Quote from: Nila on October 31, 2003, 06:08:18 am

INSERT INTO 'tablename' (`fieldname1`, `fieldname2`, `etc`) VALUES ('value1', 'value2', 'value3')

repeated for each file - so for ten files u'd have ten lines repeating that.

Yeah... that's pretty easy. It'd take less than five minutes to write the XSLT for that. Are there any perofrmance hits to executing thousands of SQL statements one at a time? Would the DB import function (I can't think of a DB app that doesn't have an XML import functionality) scale better?

I was thinking you wanted SQL statements to cut up the XML into many different lookup tables. It's not much of a database (certainly not normalized!) if it's just a single table.

If you want the XSLT, let me know.

Scott-

sraymond · « **Reply #33 on:** October 31, 2003, 10:29:46 am »

Quote from: hit_ny on October 31, 2003, 02:27:03 am

Quote
Can you give me an example of how you'd find the DTD useful?

i would import it into access after the library xml, i'm hoping access will be able to make more sense of the library XML.

Currently it only shows ITEM after import.

i would expect one table with all the attributes displayed as columns. i think once this is done, if any further tables need to be created, it wont be too difficult to do so within access itself.

The DTD won't help you any for that... the MPL format is just a bunch of <Item> elements (one per media file) each with a funch of <Field> elements containing the tag inforrmation (the <Field> has a "Name" attribute that identifies what tag). If you're looking for a single table, that's pretty easy. I remember someone asking for an XSLT that put the MPL into an Access friendly format. If a serach on INTERACT turns up empty, I'll do it for you.

Scott-

hit_ny · « **Reply #34 on:** October 31, 2003, 10:58:08 am »

Quote

If you're looking for a single table, that's pretty easy. I remember someone asking for an XSLT that put the MPL into an Access friendly format. If a serach on INTERACT turns up empty, I'll do it for you.

Thx for the offer

did a search and came up empty.

this is exactly what i am looking for.

the only entity is track ( or item as JRiver calls it) therfore one track table and everything else is an attribute of track.

I am wondering why the columns were represented as attributes rather than Elelments. This seems to be a debatable topic on style in the XML modelling world.

sraymond · « **Reply #35 on:** October 31, 2003, 11:16:18 am »

Quote from: hit_ny on October 31, 2003, 10:58:08 am

I am wondering why the columns were represented as attributes rather than Elelments. This seems to be a debatable topic on style in the XML modelling world.

There's a very good reason for this: Imagine a custom field called "1st Person". This can't be an element name (you can't have a number in the first character and you can't have spaces in the name) - so what will you do? Putting the field name into an attribute value avoids the problem.

If you're interested in the topic of elements vs. attributes, I can send you an interesting chapter that provides some good guidance on how to decide.

Quote

this is exactly what i am looking for

How about you e-mail me (scottraymond@sbcglobal.net) a sample Access database (with the table name and column names you prefer)?

Scott-

sraymond · « **Reply #36 on:** October 31, 2003, 06:27:03 pm »

In response to ht_ny's desire to import into Access, here's a quick XSLT that puts the MPL into an Access-friendly format ready for "Import":

Code: [Select]

<?xml version='1.0'?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" indent="yes"/>
<xsl:template match="/MPL">
   <dataroot>
   <xsl:for-each select="Item">
      <Item>
      <xsl:for-each select="Field">
         <xsl:element name="{translate(@Name,' #()','_N')}">
            <xsl:value-of select="."/>
         </xsl:element>
      </xsl:for-each>
      </Item>
   </xsl:for-each>
   </dataroot>
</xsl:template>
</xsl:stylesheet>

I took the liberty of automatically converting the MPL Field Name to something XML-legal by replacing <space> with "_", "#" with "N", and removing "(" and ")". The alternative is to manually catch each MPL Field Name and insert the desired element.

A guess the more elegant solution is to escape the illegal characters in the element name itself - the same way Access does when exporting the database to XML. I don't know of an easy way to do that off the top of my head, but maybe if I googled some more I could figure it out.

If you want to save the result of the applied XSLT, my suggestion is to download Microsoft's Microsoft XML Parser 3.0 SP 4 (available from http://msdn.microsoft.com/library/default.asp?url=/downloads/list/xmlgeneral.asp). There is included in this a command-line XSLT processor called MSXSL.EXE. You can just use MSXSL by typing "msxsl <input> <xslt> -o<output>". If you don't want to hassle with paths, you might just copy the MSXSL.EXE to the same folder as you put your export.

If Scott. can implement the suggestion to allow the application of an XSLT to his MCXMLExport plugin and a saving of the result, you can avoid the step of transforming manually.

Any questions, let me know.

Scott-

hit_ny · « **Reply #37 on:** November 02, 2003, 05:41:19 am »

Many thanks for the XSL scott. It converts the attributes from the exported XML into XML compliant ELEMENT names. That cmd-line XML parser worked fine.

I suppose this brings back the attributes vs ELEMENTS debate again.

If xml compliant ELEMENT names are chosen instead of attribute names as is the case now, then does it not seem easier if ELEMENTS were chosen intead of attributes ?

The parsed XML imported fine into access and displayed he ELEMENT names as coilumn names.

It works just great in Access, now i can display the data as i want.

sraymond · « **Reply #38 on:** November 02, 2003, 11:33:32 am »

Quote

If xml compliant ELEMENT names are chosen instead of attribute names as is the case now, then does it not seem easier if ELEMENTS were chosen intead of attributes?

Currently, the field names are stored in the attribute value, not the attribute name; naming rules for attributes are the same as for elements.

JRiver could choose to follow XML element naming rules for their standard field names, but what about customizations? They'd have to include a regular expression validator to ensure that users didn't create their own field names that failed to conform to XML element naming rules. All-in-all, I think it's a bad idea to to apply XML rules to a relational database when you can always apply the rules when doing the export to XML.

I don't see JRiver changing their MPL shcema... though Scott. could do this with the MCXMLExport plugin. But I can't think of any reason why this would be necessary. Do you have something in mind?

Scott-

hit_ny · « **Reply #39 on:** November 03, 2003, 02:01:09 am »

Quote

JRiver could choose to follow XML element naming rules for their standard field names, but what about customizations? They'd have to include a regular expression validator to ensure that users didn't create their own field names that failed to conform to XML element naming rules.

Right... i suppose the key here is the difficulty/feasibility in making that validator.

Quote

All-in-all, I think it's a bad idea to to apply XML rules to a relational database when you can always apply the rules when doing the export to XML.

you got a point there, i thought the exported xml was not useful to me, until you stepped in with the XSLT.

Quote

I don't see JRiver changing their MPL shcema... though Scott. could do this with the MCXMLExport plugin. But I can't think of any reason why this would be necessary. Do you have something in mind?

i dont have anything in mind except ease of use, just wondered why they chose attribute values over elements. I suppose not having any control over customisations forced the isue. If one can massage the format using XSL then i suppose the format JRiver provides is sufficient. ( I am referring to main Library export and not what the thread title is asking for, this still needs to be requested from JRiver)

i am still a XML newbie and had read in a book the foll.

"A lot of debate rages over when you should store data using attributes and when you should store data using elements. There simply is no hard and fast rule, but here are a couple of guidelines that I find useful. First, too many attributes definitely make documents hard to read.

Another point is that you really can't specify document structure using attributes

deciding whether to store your data in attributes or create new elements is really a matter of taste?until you get beyond a few attributes per tag. If you find yourself using (not just defining, but using) more than four attributes in a tag, consider breaking up the tag into a number of enclosed tags. Doing so will make the document structure much easier to work with and edit later"

sraymond · « **Reply #40 on:** November 03, 2003, 09:51:09 am »

Quote

( I am referring to main Library export and not what the thread title is asking for, this still needs to be requested from JRiver)

Oh... Scott. has developed an *AWESOME* plugin that does all (and more) that anyone could have expected. It really is great - try it out.

Here's a screenshot: http://homepages.paradise.net.nz/~scottray/mcxml/mcxmlb2preview.jpg

Here's the latest thread (with a link to the download): http://yabb.jriver.com/interact/index.php?board=5;action=display;threadid=16536

Scott-

sraymond · « **Reply #41 on:** November 09, 2003, 08:19:25 pm »

hit_ny,

Quote

i am still a XML newbie and had read in a book the foll.

"A lot of debate rages over when you should store data using attributes and when you should store data using elements. There simply is no hard and fast rule, but here are a couple of guidelines that I find useful. First, too many attributes definitely make documents hard to read.

Another point is that you really can't specify document structure using attributes

deciding whether to store your data in attributes or create new elements is really a matter of taste?until you get beyond a few attributes per tag. If you find yourself using (not just defining, but using) more than four attributes in a tag, consider breaking up the tag into a number of enclosed tags. Doing so will make the document structure much easier to work with and edit later"

I had meant to give you some reading about this... but I forgot. Oh well, better late than never. Take a look at http://pages.sbcglobal.net/scottraymond/Information%20Modeling%20with%20XML.pdf

Scott-

hit_ny · « **Reply #42 on:** November 09, 2003, 09:37:32 pm »

Quote

had meant to give you some reading about this... but I forgot. Oh well, better late than never. Take a look at http://pages.sbcglobal.net/scottraymond/Information%20Modeling%20with%20XML.pdf

Thank You

Phydeaux · « **Reply #43 on:** November 10, 2003, 09:26:20 am »

I'm no XML guru, but why are the fields called: <Field name="blah"> instead of <Blah>?

These can all be defined very easily in an automatically generated DTD statement at the top. It's just odd.

P.

sraymond · « **Reply #44 on:** November 10, 2003, 09:47:04 am »

Quote from: Phydeaux on November 10, 2003, 09:26:20 am

I'm no XML guru, but why are the fields called: <Field name="blah"> instead of <Blah>?

These can all be defined very easily in an automatically generated DTD statement at the top. It's just odd.

P.

Element naming rules in XML place some restrictions on what are valid field names. This is a common "problem" when going from a relational database to XML. There are basically two choices: escape the invalid characters (spaces, some symbols, etc.) or put the names in an attribute value (not the attribute name, because it has the same naming restrictions). Or, you could avoid the invalid characters in the first place - but customization of fields makes this difficult to enforce.

MS Access uses the "escape invalid characters" solution... but it becomes a bit of a pain when dealing with all the "_x0020_" that come from spaces (which are quite common in some peoples naming convention of field names.

All-in-all, I think JRiver has used the easier of solutions. You can use XSLT to transform from one solution to the other, so I don't see it as a big deal.

I've discussed this a bit in this thread... you can read previous posts and see if I'm being consistent.

Scott-

sraymond · « **Reply #45 on:** November 11, 2003, 04:02:39 pm »

I read this recently on the XML-DEV list:

"A lot of people nowadays forget that the M in XML stands for markup.
Markup is a noun derived from a verb: it implies that you start with a
piece of continuous text, and you then annotate it, without changing the
original content.

So the original motivation for the difference between attributes and
child elements is that child elements contain the original data and
attributes contain the annotations.

- Michael Kay"

INTERACT FORUM

Author Topic: REQ: Improved XML Export (Read 5369 times)

sraymond

sraymond

sraymond

sraymond

sraymond

nila

sraymond

sraymond

sraymond

nila

nila

sraymond

sraymond

nila

sraymond

sraymond

sraymond

sraymond

sraymond

sraymond

sraymond

sraymond

sraymond