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.
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.
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"