How do you believe Metadata changes should be approached in the following cases?
1) If the reason for the Metadata change is the introduction of a new business rule that will require code changes. 2) If the reason for the Metadata change is simply to capture more data that is non-essential to any transaction processing. The last idea on this thread was that EVERY thing should be in database... I thought about that for like 1 nanosecond and agreed. Because that way...a version stamp could be applied that "pinned" the XML, the XSD, the XSL and the actual processing code (ASP, JAVA, PHP, whatever) Is this thread going anywhere? I am sorry if this is quasi not CMS...but I am designing the update to a CMS product and all of these issues have been keeping up night after night for about a week. So is it ok to use this list for peer design review questions???? I hope so. I can always -- "off-list" the hardcore XSD/XSL/XML stuff to be fair to all of you nice people. -Tony Leotta -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Mattias Konradsson Sent: Thursday, February 06, 2003 10:41 AM To: tonyl/pillarsoftware; 'Jonathan Peterson'; [EMAIL PROTECTED] Subject: Re: [cms-list] managing metadata; Perfomance Here's some of my experience: > Tony Wrote: > Would you store XML as BLOBs in a RDBMS? Pros/cons? > Would you store XSLTs as BLOBs in a RDBMS? Pros/cons? > I think XSLTS should be stored on disk...but XML data can be stored in > many ways...Mapped, as BLOBS, etc. I came to the overall conclusion when working on a enterprise grade cms that it's best to store *everything* in the database, xml documents, xslt stylesheets images etc etc, that way you have everything nice and centrally making it easy to make backups and keeping transactional integrity. I do however "push" out the content to the middle-layer servers so the templates and xml documents get written to the FS on each middle-tier server. This gives you the best of both worlds when it comes to performance and security. > Have you ever generated XSLTs from a scripts BEFORE they are used to > transform? > > Have you ever tried using multiple XSLTs to generate just one output > page or pages. I am considering using a different XSLT process to > transform each "region" of a page. Any thoughts? I've used that technique but found it a better way to assemble on big stylesheet by the use of includes, this makes it much easier and flexible to transform documents and you can do cool things like inheritance and overriding templates. It also relieves you of the burden of identifying which template should be used for transformation, you simply serve upp templates that match the data in the aggregated stylesheet and it will take care of it. Performance might be an issue but in .Net for example you can cache a compiled instance of a stylesheet minimizing this issue. <signature> <email>[EMAIL PROTECTED]</email> <mobile country="+46" area="709" number="284262"/> <company>Existic</company> </signature> -- http://cms-list.org/ more signal, less noise. -- http://cms-list.org/ more signal, less noise.
