http://www.altova.com/ Altova accelerates application development and data management projects with software and solutions that enhance productivity and maximize results. As an innovative, customer-focused company and the creator of XMLSpy and other leading XML, data administration, UML, and Web services tools, Altova is the choice of over 3 million clients worldwide, including virtually every Fortune 500 company. With customers ranging from vast development teams in the world’s largest organizations to progressive one-person shops, Altova’s line of software applications fulfills a broad spectrum of business needs. Altova is an active member of the World Wide Web Consortium (W3C) and Object Management Group (OMG) and is committed to delivering standards-based platform-independent solutions that are powerful, affordable, and easy to use. Altova was founded in 1992 and has headquarters in Beverly, Massachusetts and Vienna, Austria. en-us Copyright © 2005, 2006, 2007 Altova GmbH. All rights reserved. Altova, XMLSpy, MapForce, StyleVision, SemanticWorks, SchemaAgent, UModel, DiffDog, and Authentic are trademarks and/or registered trademarks of Altova GmbH in the United States and/or other countries. The names of and reference to other companies and products mentioned herein may be the trademarks of their respective owners. Tue, 03 Jun 2008 10:00:00 EDT Tue, 03 Jun 2008 10:00:00 EDT Authentic RSS Editor, visit www.altova.com for details pr@altova.com webmaster@altova.com http://www.altova.com/images/logos/altova_right_120.gif http://www.altova.com/ 120 24 Altova Logo Mukul Gandhi wrote: > My point was, that XSD and DTD (and also XML) are "W3C" specs. RelaxNG > is an OASIS specification. I haven't seen W3C specs, recommendating > users to use OASIS specs, *and* mentioning these statements in W3C > specs themselves. Or do we have any instances of W3C specs, where W3C > recommends users to use certain OASIS specs. This more so doesn't > happen if W3C and OASIS develop competing languages. But I don't see > XSD and RelaxNG as competing to each other. > > W3C SVG for example uses RELAX NG not XSD. http://www.w3.org/TR/SVGTiny12/ > My simple point was, that XML spec mentions DTD as a validation > technology but it doesn't mention today XSD it's spec. And XSD is > another validation technology from W3C, which is vastly better than > DTD and is a pretty stable language now. > Pretty stable? How many full implementations are there of XSD 1.1 today (apart from Michael's?) Microsoft isn't supporting it AFAIK. Libxml's front page says it only has a partial implementation of XSD 1.0. And Mukul's Xerces release won't be out until December, will it, hence the spruiking I guess? >> Just like picking a programming language you >> are free to pick the validation method you want to use. >> > > I agree. But my point as I have been saying in this thread, was that > XML mentions DTD, but it doesn't mention XSD. This gives a naive user > a feeling, that DTD is something which is integral to XML, while XSD > is not. I believe, this should be corrected in XML spec. > Err...the naive user is correct. The entity mechanism is integrated in XML, it is not a severable layer. Entities are declared with the DTD mechanism; XSD provides no alternative to this. Cheers Rick Jelliffe _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306287.html Len Bullard wrote: > No. I think it was a way of saying something simple and familiar will work > until something more precise and powerful can replace it. It was a > stabilizer in a time of incredible shifts and unpredictable fortunes. It's > clear that validity is not intrinsic to markup functionally. It is just as > clear that validation is useful to applications. > DTDs provide a convenient summary and test of a document; they allowed and encouraged a basic level of test-driven development in an area with a lot of cowboy programmers. When the summary becomes larger than the document, and the test becomes more difficult to debug than to do by hand, then DTDs are not much use. Which is why so many small XML documents don't have them. But you need a fairly large document for an XSD schema to be useful to programmers as a summary, and you need a very complex document before the schema is less difficult to install and debug than just inspecting the documents or writing your own tests. The main problem with DTDs is not that they are flawed (they are nice simple, modest, inoffensive little things), but that that DTDs limited the expectations of the initial XSD Schema WG, many of whom had never written a schema or DTD IIRC*, about what a schema was supposed to do. Questions that could have been asked early include "Can this support HTML?", "Can this support SVG?", "Can this support RDF?", "Can this support XSLT?", "Can this support RSS?" Instead, what we got was "Can this support Postal Addresses?" Cheers Rick Jelliffe * When I was on the XSD Working Group (a decade ago), any reference I made to "idiomatic usages of XML" seemed to be met with utter incomprehension and dismissal, as if it were an eccentric concern. Consequently, at the last minute, when XSD was finally tested against real schemas such as HTML, it was found to need revisions: the whole complex-type derivation system was found inadequate and the <redefine> escape hatch had to be provided, for example. Now, after 10 years, we can see some recognition of this, in that XSD 1.1 has some idea that attributes might actually be used to make decisions on content. (Of course, instead of the neat RELAX NG way, XSD implements it by tacking it on outside content models, the chance for more bogus complexity being too irresistable, I suppose.) _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306286.html Mukul Gandhi wrote: > Since DTD is already mentioned in the XML spec, why not specify XSD as > well as a normative reference to a future XML spec? Because XSD is complete crap that utterly betrayed the premises and goals of XML perhaps? > I think, mentioning XSD in the XML spec will encourage users to use > XSD as a better validation technology, than DTD. Mentioning this as a > reference link in XML spec, looks like a very minor and non disruptive > addition to me, for the XML spec The way to use XSD as a better validation technology is to learn from it, rather than encourage it. Cheers Rick _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306283.html On Sat, Nov 7, 2009 at 10:42 PM, Simon St.Laurent <simonstl@simonstl.com> wrote: > It's supposed to hurt XSD.  If you're that attached to XSD that complaints > about XSD hurt you, I'm afraid you may be too attached to the technology. I am not too attached to any technology, whatsoever. Any technology that can solve business and societal issue, is good for me. > Unfortunately, it's also brittle, barely able to represent some common > structures, offers extensibility mechanisms that aren't very extensible, and > has lots of corners that aren't implemented consistently. As I wrote earlier, I don't intend to judge the merits of XSD language as such, or compare all or any of XML Schema language. Any language (I mean, the XML Schema languages as we are discussing here) has certain design goals, and all computational languages are generally nice if they have met their stated design goals. What people are saying about RelaxNG or Schematron cannot apply to XSD, as design goals of XSD were different. And this should be true vice versa as well. If a community is concerned about features of any of the languages, the language can modify itself probably keeping in mind, various factors involved like cost, benefits and so on. > Worst of all, its W3C-blessed status often ends conversation, which can be > poisonous for projects that would have done better with DTDs, RELAX NG, > Schematron, a combination of those, no schema whatsoever, or something else > entirely. I don't think, saying phrases like "poisonous" helps to solve a design mistake in a spec, from a standard body :( > Politically, of course it's possible.  And maybe the W3C, which is normally > (though not always) fond of its works, will decide to add such a reference. I am not suggesting to solve this issue politically. I intend to get this solved, as a sound computational design issue. -- Regards, Mukul Gandhi _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306272.html Thanks, Jim for some nice comments. My intention was not to say, that DTD is now not useful. As you rightly said, DTD is still preferred over XSD for certain class of problems. My averment was to give XSD the same status as DTD, as a XML validation technology in W3C XML spec. On Sun, Nov 8, 2009 at 1:31 AM, Jim Melton <jim.melton@acm.org> wrote: > I'm one of those people who don't fall in love with technologies for their > own sake, regardless of how beautiful and/or useful they might be.  I do > have a fondness for elegance, as well as for practicality, but I believe > that technology provides tools and nothing more.  XSD is one such tool, DTD > is another.  Each has its uses, and I use them both. > > As Simon has pointed out, DTDs do a great job for document-centric > applications where there is little that needs to be known about the > semantics of atomic data types.  I use DTDs for my editing work on the SQL > standard and on W3C documents, as well as for a host of other documents I do > in other aspects of my day job and my life. > > Schemas are often very clumsy for validating "ustructured" textual > documents, such as fiction books, biographies, and the like.  But schemas > (XSD being the W3C-defined instance of this technology) are very useful when > dealing with structured documents, especially those that contain lots of > traditional data and/or those that are generated specifically from data (not > to mention those that *are* data expressed in an XML tree). > > I get very, very frustrated when I'm trying to drive a nail into their wall > using a screwdriver, as well as when I'm trying to get a screw out of the > wall using a hammer.  That doesn't make me hate the screwdriver or the > hammer -- nor, for that matter, to love either one when I figure out that I > got it backwards and start using the proper tool for each job.  They're just > tools.  Pick the right one for your job. > > If your management is forcing you to use XSD for unstructured document > validation (or DTDs for highly structured data validation), don't hate XSD > (or DTD)...hate the bureaucracy that limits your choice of tool! > > Hope this helps, >   Jim > > ======================================================================== > Jim Melton --- Editor of ISO/IEC 9075-* (SQL)     Phone: +1.801.942.0144 >  Chair, W3C XML Query WG; XQX (etc.) editor       Fax : +1.801.942.3345 > Oracle Corporation        Oracle Email: jim dot melton at oracle dot com > 1930 Viscounti Drive      Standards email: jim dot melton at acm dot org > Sandy, UT 84093-1063 USA          Personal email: jim at melton dot name > ======================================================================== -- Regards, Mukul Gandhi _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306271.html On Sat, Nov 7, 2009 at 10:15 PM, Dan Vint <dvint@dvint.com> wrote: > Why and where do you stop? RelaxNG is another standard for providing > validation and has a different/additional set of capabilities that are > missing in both schema and DTD validation. My point was, that XSD and DTD (and also XML) are "W3C" specs. RelaxNG is an OASIS specification. I haven't seen W3C specs, recommendating users to use OASIS specs, *and* mentioning these statements in W3C specs themselves. Or do we have any instances of W3C specs, where W3C recommends users to use certain OASIS specs. This more so doesn't happen if W3C and OASIS develop competing languages. But I don't see XSD and RelaxNG as competing to each other. My simple point was, that XML spec mentions DTD as a validation technology but it doesn't mention today XSD it's spec. And XSD is another validation technology from W3C, which is vastly better than DTD and is a pretty stable language now. I think, we are not debating just now about the shortcomings of XSD. Even DTD has shortcomings (I think, that's why XSD was developed), but it's mentioned in the XML spec. I think, even RelaxNG has had certain design goals, and it doesn't provides some of the capabilities with XSD or DTD provides. Looking at the XML spec, the XML spec seems to convey that DTD is an inseparable part of XML definition. But if DTD is inseparable from XML, why cannot XML spec say that XSD can be used for validation as well (since XSD is a better XML validation technology, and is also developed by W3C)? > The history of XML is SGML and the use of DTDs. DTDs and SGML were initially intended > for textual manual with little to know data types. A DTD is powerful enough > to handle that requirement very well without overly complicating the > specification of the document content. That's history, and was the starting point I guess. But now, data/messages is another important paradigm other than documents. Keeping in view the evolution of XML (from documents to "documents & data types"), XML validation is now an important concern for any kind of XML data, whether that can be documents or data/messages. > Just like picking a programming language you > are free to pick the validation method you want to use. I agree. But my point as I have been saying in this thread, was that XML mentions DTD, but it doesn't mention XSD. This gives a naive user a feeling, that DTD is something which is integral to XML, while XSD is not. I believe, this should be corrected in XML spec. > Would you have the standard for C point a > programmer to Java, C#, etc just because they are newer and provide the > same/similar/better functionality? I agree. That won't be correct. A C spec cannot point users to Java, C# etc. But I think, this argument doesn't map well to DTD and XSD case. I even think, that a future XML spec other than referring to XSD as an alternative XML validation technology with DTDs, should also provide means to embed XML Schema's inline the XML documents, as we do with DTDs. I just could find this reference where Microsoft support inline XSD's starting from MSXML 5.0 (ref, http://msdn.microsoft.com/en-us/library/ms759142(VS.85).aspx). I think, this design principle can be incorporated to the XML spec (or is this already defined somewhere in W3C specs?). I could also find this reference related to this, http://xsd.stylusstudio.com/2005Mar/post03007.htm, which seem to explain this design aspect from the point of view of XML spec. -- Regards, Mukul Gandhi _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306268.html ++1 len -----Original Message----- From: Jim Melton [mailto:jim.melton@acm.org] Sent: Saturday, November 07, 2009 2:01 PM To: xml-dev@lists.xml.org Subject: Re: [xml-dev] XML spec and XSD I'm one of those people who don't fall in love with technologies for their own sake, regardless of how beautiful and/or useful they might be. I do have a fondness for elegance, as well as for practicality, but I believe that technology provides tools and nothing more. XSD is one such tool, DTD is another. Each has its uses, and I use them both. As Simon has pointed out, DTDs do a great job for document-centric applications where there is little that needs to be known about the semantics of atomic data types. I use DTDs for my editing work on the SQL standard and on W3C documents, as well as for a host of other documents I do in other aspects of my day job and my life. Schemas are often very clumsy for validating "ustructured" textual documents, such as fiction books, biographies, and the like. But schemas (XSD being the W3C-defined instance of this technology) are very useful when dealing with structured documents, especially those that contain lots of traditional data and/or those that are generated specifically from data (not to mention those that *are* data expressed in an XML tree). I get very, very frustrated when I'm trying to drive a nail into their wall using a screwdriver, as well as when I'm trying to get a screw out of the wall using a hammer. That doesn't make me hate the screwdriver or the hammer -- nor, for that matter, to love either one when I figure out that I got it backwards and start using the proper tool for each job. They're just tools. Pick the right one for your job. If your management is forcing you to use XSD for unstructured document validation (or DTDs for highly structured data validation), don't hate XSD (or DTD)...hate the bureaucracy that limits your choice of tool! Hope this helps, Jim ======================================================================== Jim Melton --- Editor of ISO/IEC 9075-* (SQL) Phone: +1.801.942.0144 Chair, W3C XML Query WG; XQX (etc.) editor Fax : +1.801.942.3345 Oracle Corporation Oracle Email: jim dot melton at oracle dot com 1930 Viscounti Drive Standards email: jim dot melton at acm dot org Sandy, UT 84093-1063 USA Personal email: jim at melton dot name ======================================================================== = Facts are facts. But any opinions expressed are the opinions = = only of myself and may or may not reflect the opinions of anybody = = else with whom I may or may not have discussed the issues at hand. = ======================================================================== _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306259.html I'm one of those people who don't fall in love with technologies for their own sake, regardless of how beautiful and/or useful they might be. I do have a fondness for elegance, as well as for practicality, but I believe that technology provides tools and nothing more. XSD is one such tool, DTD is another. Each has its uses, and I use them both. As Simon has pointed out, DTDs do a great job for document-centric applications where there is little that needs to be known about the semantics of atomic data types. I use DTDs for my editing work on the SQL standard and on W3C documents, as well as for a host of other documents I do in other aspects of my day job and my life. Schemas are often very clumsy for validating "ustructured" textual documents, such as fiction books, biographies, and the like. But schemas (XSD being the W3C-defined instance of this technology) are very useful when dealing with structured documents, especially those that contain lots of traditional data and/or those that are generated specifically from data (not to mention those that *are* data expressed in an XML tree). I get very, very frustrated when I'm trying to drive a nail into their wall using a screwdriver, as well as when I'm trying to get a screw out of the wall using a hammer. That doesn't make me hate the screwdriver or the hammer -- nor, for that matter, to love either one when I figure out that I got it backwards and start using the proper tool for each job. They're just tools. Pick the right one for your job. If your management is forcing you to use XSD for unstructured document validation (or DTDs for highly structured data validation), don't hate XSD (or DTD)...hate the bureaucracy that limits your choice of tool! Hope this helps, Jim ======================================================================== Jim Melton --- Editor of ISO/IEC 9075-* (SQL) Phone: +1.801.942.0144 Chair, W3C XML Query WG; XQX (etc.) editor Fax : +1.801.942.3345 Oracle Corporation Oracle Email: jim dot melton at oracle dot com 1930 Viscounti Drive Standards email: jim dot melton at acm dot org Sandy, UT 84093-1063 USA Personal email: jim at melton dot name ======================================================================== = Facts are facts. But any opinions expressed are the opinions = = only of myself and may or may not reflect the opinions of anybody = = else with whom I may or may not have discussed the issues at hand. = ======================================================================== _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306253.html Michael Kay wrote: >> Complex data structures seem to lead to loathing... > > I think we have a terrible tendency in this industry to confuse aesthetic > and utilitarian judgements. A thing of great ugliness can sometimes also be > of great utility; conversely, there are languages that are beautiful but > useless. I should probably be clearer - these stories weren't coming from architecture astronauts or aesthetes. They were generally coming from people who found themselves trapped by schemas other people had created, in which they then had to find a place for their data and processes. Some of them came from people who had in fact built those traps for themselves. And doubtless some of the issues were the results of style choices by those creating the schemas, not necessarily the specification itself. > Almost everyone finds XML Schema ugly. But a lot of people also find > it useful. Ugliness alone is not a problem - brambles can certainly produce delicious fruit. But brambles also produce spiky thickets that are hard to move through, or modify. -- Simon St.Laurent http://simonstl.com/ _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306248.html > Complex data structures seem to lead to loathing... I think we have a terrible tendency in this industry to confuse aesthetic and utilitarian judgements. A thing of great ugliness can sometimes also be of great utility; conversely, there are languages that are beautiful but useless. Almost everyone finds XML Schema ugly. But a lot of people also find it useful. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306245.html Michael Kay clarified for me: > I think Simon is probably thinking in terms of opportunity costs. That is, > the idea that if this technology hadn't been so widely adopted, the > community might have adopted something better instead, and gained a better > return on its investment. Yes, that's a key part of the argument. I think the W3C generally did a good job of creating XML specifications when it was stripping them down based on SGML experience. After that initial process, though, their inventions are not nearly as impressive. Other people and organizations did a much better job of creating useful tools, but lack the W3C brand power. > He might also be thinking that for some people who have adopted the > technology, the cost has been greater than the benefit. I think it would be > hard to demonstrate that objectively. In the big picture, you're quite correct that it would be hard to demonstrate that objectively. It would require access to stories and data that aren't likely to be shared and are often difficult to measure. Anecdotally, I've encountered people who love W3C XML Schema and people who despise it. Their fondness or loathing for it seems to depend on what they tried to use it for. Complex data structures seem to lead to loathing, as do document-centric projects. Versioning in particular seems to lead to loathing, except in extremely simple projects. I am, of course, pretty well-known to be a critic of the technology, so I'm sure there's a bias in which stories people choose to tell me. -- Simon St.Laurent http://simonstl.com/ _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306240.html > > I don't know, how a technology (i.e, XSD..) that is capable > of doing XML validation (and XSD does this well), and is > implemented by number of XML products, which is implemented > widely in XML applications (I can see uncountable XML > instances been validated by XSD every day), can be damaging. I think Simon is probably thinking in terms of opportunity costs. That is, the idea that if this technology hadn't been so widely adopted, the community might have adopted something better instead, and gained a better return on its investment. He might also be thinking that for some people who have adopted the technology, the cost has been greater than the benefit. I think it would be hard to demonstrate that objectively. > > I am asking only for a simple reference in the XML spec, > pointing to the XSD spec and ideally saying somewhere in the > XML spec (2.0 perhaps), that XSD is another validation > technology from W3C similar to DTD. > I still cannot think, why anybody can disagree to this. XSD > and DTD both belong to W3C, and both are W3C recommendations, > so I don't think why this simple modification to XML spec > cannot take place. > We're dealing here with specifications: a legalistic contract between the implementor of an XML parser and the user of an XML parser. You can write a fully conformant XML parser without ever knowing that XSD even exists. Furthermore, you can use XML without ever knowing that XSD exists. Therefore, XSD doesn't need to be part of the XML contract. Equally, you wouldn't want XML to be mentioned in the Unicode specifications, because Unicode has no dependency on XML, and would still be of value if everyone suddenly decided to abandon XML and move to YML instead. It's of great value that specifications should NOT have unnecessary dependencies. The fact that XML links normatively to DTDs is undoubtedly a bad thing. In this respect the architecture of specifications is very like the architecture of software implementations: you want the components to be as loosely coupled as you can achieve, to allow each component to evolve or to be replaced with minimum impact on the other components. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306239.html Mukul Gandhi wrote: > On Sat, Nov 7, 2009 at 7:38 PM, Simon St.Laurent <simonstl@simonstl.com> wrote: >> Leaving aside the question of how damaging W3C XML Schema has >> been > > I am not sure, how to respond to this. I guess this statement > certainly hurts the XSD community, and it certainly does hurt me. It's supposed to hurt XSD. If you're that attached to XSD that complaints about XSD hurt you, I'm afraid you may be too attached to the technology. > I don't know, how a technology (i.e, XSD..) that is capable of doing > XML validation (and XSD does this well), and is implemented by number > of XML products, which is implemented widely in XML applications (I > can see uncountable XML instances been validated by XSD every day), > can be damaging. XSD is good for exactly two reasons: * It starts conversation. * It's widely deployed. Unfortunately, it's also brittle, barely able to represent some common structures, offers extensibility mechanisms that aren't very extensible, and has lots of corners that aren't implemented consistently. The XQuery folks encountered yet another set of problems in creating models based on it. Worst of all, its W3C-blessed status often ends conversation, which can be poisonous for projects that would have done better with DTDs, RELAX NG, Schematron, a combination of those, no schema whatsoever, or something else entirely. >> I suspect that counting validation as a fourth component might have eased >> some problems all around, but that wasn't clear at the outset. That kind of >> change seems like a project for XML 2.0, not for an edition change. > > I'll be happy with XSD being specified in XML 2.0, if it can be. Hopefully not. >> (And, of course, I'd argue hard against any effort to incorporate W3C XML >> Schema explicitly into XML 2.0....) > > I am asking only for a simple reference in the XML spec, pointing to > the XSD spec and ideally saying somewhere in the XML spec (2.0 > perhaps), that XSD is another validation technology from W3C similar > to DTD. > I still cannot think, why anybody can disagree to this. XSD and DTD > both belong to W3C, and both are W3C recommendations, so I don't think > why this simple modification to XML spec cannot take place. Politically, of course it's possible. And maybe the W3C, which is normally (though not always) fond of its works, will decide to add such a reference. That would strike me as a continuation of the mistakes they've already made, but wouldn't be surprising. -- Simon St.Laurent http://simonstl.com/ _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306238.html At 11:12 AM 11/7/2009, you wrote: >I am asking only for a simple reference in the XML spec, pointing to >the XSD spec and ideally saying somewhere in the XML spec (2.0 >perhaps), that XSD is another validation technology from W3C similar >to DTD. >I still cannot think, why anybody can disagree to this. XSD and DTD >both belong to W3C, and both are W3C recommendations, so I don't think >why this simple modification to XML spec cannot take place. Why and where do you stop? RelaxNG is another standard for providing validation and has a different/additional set of capabilities that are missing in both schema and DTD validation. I think you may have missed a subtle point when I read: 'uncountable XML instances been validated by XSD every day'. Sounds like your dealing with data/messages, Len mentioned documents (tech manuals and such). The history of XML is SGML and the use of DTDs. DTDs and SGML were initially intended for textual manual with little to know data types. A DTD is powerful enough to handle that requirement very well without overly complicating the specification of the document content. Yes DTD didn't provide everything that everyone might need, Schema provides more capability, but still relationships between elements and part of a document are not possible to validate with a DTD or Schema. Just like picking a programming language you are free to pick the validation method you want to use. I guess I'm confused at why a reference is needed. Ok, yeah there are new and different ways of providing the validation for which v1 of the XML standard were developed. Would you have the standard for C point a programmer to Java, C#, etc just because they are newer and provide the same/similar/better functionality? ..dan --------------------------------------------------------------------------- Danny Vint Panoramic Photography http://www.dvint.com voice: 502-749-6179 _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306235.html On Sat, Nov 7, 2009 at 7:38 PM, Simon St.Laurent <simonstl@simonstl.com> wrote: >  Leaving aside the question of how damaging W3C XML Schema has > been I am not sure, how to respond to this. I guess this statement certainly hurts the XSD community, and it certainly does hurt me. I don't know, how a technology (i.e, XSD..) that is capable of doing XML validation (and XSD does this well), and is implemented by number of XML products, which is implemented widely in XML applications (I can see uncountable XML instances been validated by XSD every day), can be damaging. > I suspect that counting validation as a fourth component might have eased > some problems all around, but that wasn't clear at the outset. That kind of > change seems like a project for XML 2.0, not for an edition change. I'll be happy with XSD being specified in XML 2.0, if it can be. > (And, of course, I'd argue hard against any effort to incorporate W3C XML > Schema explicitly into XML 2.0....) I am asking only for a simple reference in the XML spec, pointing to the XSD spec and ideally saying somewhere in the XML spec (2.0 perhaps), that XSD is another validation technology from W3C similar to DTD. I still cannot think, why anybody can disagree to this. XSD and DTD both belong to W3C, and both are W3C recommendations, so I don't think why this simple modification to XML spec cannot take place. -- Regards, Mukul Gandhi _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306234.html No. I think it was a way of saying something simple and familiar will work until something more precise and powerful can replace it. It was a stabilizer in a time of incredible shifts and unpredictable fortunes. It's clear that validity is not intrinsic to markup functionally. It is just as clear that validation is useful to applications. We let the next thing go too far in terms of application. We needed multiple validators for different users and uses. We have that now but also we have entrenched factions of users. len -----Original Message----- From: Mukul Gandhi [mailto:gandhi.mukul@gmail.com] Sent: Saturday, November 07, 2009 9:25 AM To: Michael Sokolov Cc: Michael Kay; xml-dev@lists.xml.org Subject: Re: [xml-dev] XML spec and XSD On Sat, Nov 7, 2009 at 7:04 PM, Michael Sokolov <sokolov@ifactory.com> wrote: > There seems to have > been an insistence on making validity a property of the document, rather > than a separate concern. I think, presence of DTD in the XML spec exactly says this (i.e, validity is a concept inseparably tied to XML markup). But of course, XML document validity is optional for applications to perform. Since DTD is already mentioned in the XML spec, why not specify XSD as well as a normative reference to a future XML spec? I think, even an errata to a current XML spec can fix this. I am not sure, if another edition of XML is underway [1]. If that's [1] happening at W3C at the moment, it may even contain this normative reference I am suggesting. Even W3C says, that XSD replaces DTD as a better XML validation technology. And XSD 1.0 version has been in existence since many years now, and implemented by quite a few XML products, and also deployed widely in end user applications. Therefore, why XML standard cannot say that XSD is a validation technology like what DTD is? I think, mentioning XSD in the XML spec will encourage users to use XSD as a better validation technology, than DTD. Mentioning this as a reference link in XML spec, looks like a very minor and non disruptive addition to me, for the XML spec. -- Regards, Mukul Gandhi _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306230.html In my mind it wasn't clear where validation belonged and secondly who should be responsible for it being done. To clarify, SGML made it reasonably simple for a technical writer to express document definition, not validation per se, but an as-simple-as=possible 'these are the contents in the order needed for this specific task or communication'. Most of the fancy math computer sciency database stuff got ladled on to that basic need because we in the business of writing documents were increasingly writing for computer science applications instead of law, regulations, etc. We tended to bow down to the programmers. Dropping validation was on some minds most particularly the computer scientists who wanted markup to serve their needs. They have a lot of experience string schlepping and the idea that validation was necessary to define outside of their own code seemed wasteful and that at a time when every CPU cycle was sacred because scarce. To the writers having the toolkit to define the document made sense because frankly the computer scientists were even lousier at that then the lawyers had been. So markup became the possession of the computer scientists instead of the writers. It is bit like the scene in Star Wars where the Senate cheers mightily for the new Emperor. They think it a pretty good idea at the time. DTDs were and in many ways still a pretty good compromise for giving power tools to people who don't write a lot of code. XSD might have been a better compromise but once again the theoreticians, the math wonks and the compiler wonks took the field. Like a very heavy sword, it became something very powerful in the right hands and too hard to wield in others. Sad but so: Microsoft had it right in the beginning. Politics and market ideology were the avatars of local ambition. It's hard to fight a truckload of speeding money driven by ideologues at the behest of bankers. len -----Original Message----- From: Simon St.Laurent [mailto:simonstl@simonstl.com] Sent: Saturday, November 07, 2009 8:08 AM To: xml-dev@lists.xml.org Subject: Re: [xml-dev] XML spec and XSD Mukul Gandhi wrote: > But I feel, that mentioning XSD as a validation technology for XML > documents, in the XML spec is perhaps a good idea since DTD is also > mentioned in the XML spec (which is also a XML validation technology). > I feel, doing so doesn't promote any pedagogic or marketing attitudes > towards XSD. It's history. Leaving aside the question of how damaging W3C XML Schema has been, it simply wasn't part of the original XML vision. The three parts were supposed to be markup, style, and linking, learning from SGML, DSSSL, and HyTime respectively. Markup, inheriting from the SGML vision, included DTDs. I suspect that counting validation as a fourth component might have eased some problems all around, but that wasn't clear at the outset. That kind of change seems like a project for XML 2.0, not for an edition change. (And, of course, I'd argue hard against any effort to incorporate W3C XML Schema explicitly into XML 2.0....) -- Simon St.Laurent http://simonstl.com/ _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306229.html On Sat, Nov 7, 2009 at 7:04 PM, Michael Sokolov <sokolov@ifactory.com> wrote: > There seems to have > been an insistence on making validity a property of the document, rather > than a separate concern. I think, presence of DTD in the XML spec exactly says this (i.e, validity is a concept inseparably tied to XML markup). But of course, XML document validity is optional for applications to perform. Since DTD is already mentioned in the XML spec, why not specify XSD as well as a normative reference to a future XML spec? I think, even an errata to a current XML spec can fix this. I am not sure, if another edition of XML is underway [1]. If that's [1] happening at W3C at the moment, it may even contain this normative reference I am suggesting. Even W3C says, that XSD replaces DTD as a better XML validation technology. And XSD 1.0 version has been in existence since many years now, and implemented by quite a few XML products, and also deployed widely in end user applications. Therefore, why XML standard cannot say that XSD is a validation technology like what DTD is? I think, mentioning XSD in the XML spec will encourage users to use XSD as a better validation technology, than DTD. Mentioning this as a reference link in XML spec, looks like a very minor and non disruptive addition to me, for the XML spec. -- Regards, Mukul Gandhi _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306228.html Mukul Gandhi wrote: > But I feel, that mentioning XSD as a validation technology for XML > documents, in the XML spec is perhaps a good idea since DTD is also > mentioned in the XML spec (which is also a XML validation technology). > I feel, doing so doesn't promote any pedagogic or marketing attitudes > towards XSD. It's history. Leaving aside the question of how damaging W3C XML Schema has been, it simply wasn't part of the original XML vision. The three parts were supposed to be markup, style, and linking, learning from SGML, DSSSL, and HyTime respectively. Markup, inheriting from the SGML vision, included DTDs. I suspect that counting validation as a fourth component might have eased some problems all around, but that wasn't clear at the outset. That kind of change seems like a project for XML 2.0, not for an edition change. (And, of course, I'd argue hard against any effort to incorporate W3C XML Schema explicitly into XML 2.0....) -- Simon St.Laurent http://simonstl.com/ _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306225.html DTD is special, sadly. It got lodged in the XML spec in the early days, too deeply to be excised now, a legacy of SGML I think? There seems to have been an insistence on making validity a property of the document, rather than a separate concern, as it is w/XSD and others. Probably someone older and wiser can give you a more complete explanation. -Mike > -----Original Message----- > From: Mukul Gandhi [mailto:gandhi.mukul@gmail.com] > Sent: Saturday, November 07, 2009 5:49 AM > To: Michael Kay > Cc: xml-dev@lists.xml.org > Subject: Re: [xml-dev] XML spec and XSD > > Thanks, Mike for your remarks. > > On Sat, Nov 7, 2009 at 3:59 PM, Michael Kay <mike@saxonica.com> wrote: > > It's a basic issue of architectural layering. XSD has a > dependency on > > XML, XML has no dependency on XSD. Nothing in the XML spec > is affected > > if XSD changes. > > > > It's bad enough when you're writing a spec tracking the changes in > > technologies you depend on (like Unicode). Introducing unnecessary > > dependencies for pedagogic or marketing reasons would be a very bad > > thing to do. > > Looking at your view points above, I agree to them as good > architectural principles while writing W3C specs. > > But I feel, that mentioning XSD as a validation technology > for XML documents, in the XML spec is perhaps a good idea > since DTD is also mentioned in the XML spec (which is also a > XML validation technology). > I feel, doing so doesn't promote any pedagogic or marketing > attitudes towards XSD. > > Reading the XML spec, gives us a feeling (to me at least, I > guess) that DTD is the most important technology for > validating XML. Even if we don't mention specific versions of > XSD as validating language for XML documents (in specific XML > standards, like 1.0 5th edition or XML 1.1), I think it's > good to mention in references of the XML spec (I believe, a > normative reference to this would also be good in the XML > spec), that XSD is also another XML validation technology > from W3C, which achieves the same task as DTDs do. I think, > referring to the link, http://www.w3.org/XML/Schema in XML > specs would serve the purpose I am suggesting. > > > > -- > Regards, > Mukul Gandhi > > ______________________________________________________________ > _________ > > XML-DEV is a publicly archived, unmoderated list hosted by > OASIS to support XML implementation and development. To > minimize spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org List archive: > http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306222.html Thanks, Mike for your remarks. On Sat, Nov 7, 2009 at 3:59 PM, Michael Kay <mike@saxonica.com> wrote: > It's a basic issue of architectural layering. XSD has a dependency on XML, > XML has no dependency on XSD. Nothing in the XML spec is affected if XSD > changes. > > It's bad enough when you're writing a spec tracking the changes in > technologies you depend on (like Unicode). Introducing unnecessary > dependencies for pedagogic or marketing reasons would be a very bad thing to > do. Looking at your view points above, I agree to them as good architectural principles while writing W3C specs. But I feel, that mentioning XSD as a validation technology for XML documents, in the XML spec is perhaps a good idea since DTD is also mentioned in the XML spec (which is also a XML validation technology). I feel, doing so doesn't promote any pedagogic or marketing attitudes towards XSD. Reading the XML spec, gives us a feeling (to me at least, I guess) that DTD is the most important technology for validating XML. Even if we don't mention specific versions of XSD as validating language for XML documents (in specific XML standards, like 1.0 5th edition or XML 1.1), I think it's good to mention in references of the XML spec (I believe, a normative reference to this would also be good in the XML spec), that XSD is also another XML validation technology from W3C, which achieves the same task as DTDs do. I think, referring to the link, http://www.w3.org/XML/Schema in XML specs would serve the purpose I am suggesting. -- Regards, Mukul Gandhi _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306211.html > > But I wonder, why the XML spec (1.0 or 1.1) doesn't mention > XSD (i.e, W3C XML Schema language) as also a second XML > validation language (i.e, other than DTD)? I am curious to > know, was this decision not to mention XSD as a validation > technology in XML specs, was a consicous one? If yes, what > advantages we have achieved by this decision? It's a basic issue of architectural layering. XSD has a dependency on XML, XML has no dependency on XSD. Nothing in the XML spec is affected if XSD changes. It's bad enough when you're writing a spec tracking the changes in technologies you depend on (like Unicode). Introducing unnecessary dependencies for pedagogic or marketing reasons would be a very bad thing to do. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306210.html Hi all, Seeing the XML 1.0, 5th edition spec (ref, http://www.w3.org/TR/REC-xml/) I cannot find any reference to the phrase "XML Schema" or XSD (which are the XML Schema languages, defined by the W3C specs viz specified at, http://www.w3.org/XML/Schema). The XML 1.0 spec, certainly refers to the word DTD and provides the complete definition of DTD semantics, and how it integrates with XML as a validation technology. This all is great. But I wonder, why the XML spec (1.0 or 1.1) doesn't mention XSD (i.e, W3C XML Schema language) as also a second XML validation language (i.e, other than DTD)? I am curious to know, was this decision not to mention XSD as a validation technology in XML specs, was a consicous one? If yes, what advantages we have achieved by this decision? This curiousity spurs to my mind, keeping in mind that XSD is a very important XML validation technology today, which is a W3C standard and implemented widely in software applications. -- Regards, Mukul Gandhi _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306199.html What I mean by interface files is ... The database into which the XML data will be stored is just a 'staging' area. Other applications require subsets of the data in different formats that meet both their specific needs and conform to their application data models. So whilst some 'reports' may be sourced by this data directly, for the most part into is just one feed into many other 'interfaces'. Fraser. 2009/11/4 Jim Tivy <jimt@bluestream.com>: > Fraser > > Often XML coming in reflects one hierarchy of the data - for example invoice > header and details - for example, where each invoice is a customer > transaction at a CoffeeHouse Chain.  These incoming hierarchies can have > redundant information - for example the address of a customer as stated in > each invoice.  If you need to report on this data in a different hiearchy, > first you need to define an appropriate RDB application data model and then > import carefully into it to remove redudancy, normalize the data into > respective entities (tables) and generally protect and enforce the quality > of data in the database.  Then you can acurately report on the data where > the output of the report reflects a different hierarchy than the incoming > Xml data -  say, total product sales of product latte in January by City by > Store. > > In this way, the reports you need out will carry requirements for your RDB > application data model. > > Not sure what you mean by "interface files"? > > Jim > > -----Original Message----- > From: Fraser Goffin [mailto:goffinf@googlemail.com] > Sent: Wednesday, November 04, 2009 8:20 AM > To: xml-dev@lists.xml.org > Subject: Re: [xml-dev] Shredding XML > > I don't know the full detail of the interface files that will be > produced from this store, but its probably safe to assume that these > will need to model the data with multiple hierarchies and groupings. > > Whats driving this line of thought ? > > Fraser. > > 2009/11/3 Jim Tivy <jimt@bluestream.com>: >> do they need to produce reports that present the information in >> multiple hierarchial ways?  It might be invoices within a day or Lattes > sold >> within City within Province. >> >> -----Original Message----- >> From: Fraser Goffin [mailto:goffinf@googlemail.com] >> Sent: Tuesday, November 03, 2009 1:41 AM >> To: xml-dev@lists.xml.org >> Subject: Re: [xml-dev] Shredding XML >> >>> Do your applications that use the relational database need to update >> >> Thats a difficult one. As far as producing up-stream interfaces, no, >> they are created just by selecting from the database. >> >> However, as I mentioned (lost in the detail) earlier, messages >> received will have a relationship to existing records. I'm not at all >> convinced that update will be possible because not all of the keys >> will be available in the message received. Some form of 'fuzzy' >> matching may be possible in some case, for example, if I receive a new >> address then the 1st line + PostCode + the relationship of this >> address to something else may be sufficient. >> >> It might be the case that we have to consider time based snap-shots, >> i.e. the 'state' of a collection of data at a point in time. Not sure >> yet, its one of those areas of difficulty that probably doesn't change >> much whether I use relational of native XML stores. >> >> At present the primary purpose of the database is for retreival, i.e. >> its NOT an operational store, its for MI, so optimiastions for read >> rather than update are appropriate. >> >>> do they need to produce reports that present the information in multiple >> ways >> >> Yes. >> >> Fraser. >> >> 2009/11/3 Jim Tivy <jimt@bluestream.com>: >>> Do your applications that use the relational database need to update and >> do >>> they need to produce reports that present the information in multiple > ways >>> hierarchial ways?  This may suggest whether your database needs to be >>> normalized (approaching 3rd Normal form)? >>> >>> -----Original Message----- >>> From: Fraser Goffin [mailto:goffinf@googlemail.com] >>> Sent: Monday, November 02, 2009 3:31 PM >>> To: xml-dev@lists.xml.org >>> Subject: Re: [xml-dev] Shredding XML >>> >>> Hi Jim, >>> >>> thats interesting ... which should be the 'driving' schema, XML or Db ? >>> >>> I guess I've been somewhat tiptoe'ing around this one. >>> >>> I should admit my bias if its not already apparent. I work mainly in >>> the SOA integration space and since XML is the primary exchange format >>> and XML schema does a reasonable job as the type system, I favour >>> processing XML as .. well XML ... whilst I understand the argument >>> around leveraging existing technologies and skillset .. often-times >>> this is little more than protectionism and continually [de]composing >>> from XML to objects then to CopyLibs and then to relational just seems >>> unnecessary a lot of the time (sorry - soap box over).  But of course >>> the whole world isn't XML and just like most other large organisations >>> the vast majority of our processing capability and data isn't and >>> probably never will be ... I have no issue with that. >>> >>> On the one hand it is the end product that drives the design (even if >>> that design has a relatively short shelf-life ... but hey, we all do >>> agile right). In that case it is definately the Database schema that >>> prevails from the pure delivery point of view, since this is the >>> desired source for the staging area from which to produce interface >>> files for upstream applications. At present there appears to be no >>> possiblility of revisiting that choice. At the same time, I don't want >>> to 'paint myself into a corner' or promote this as an exemplar for all >>> future approaches (unless it turns out that way :-) >>> >>> My unease is around the brittleness of the database schema in the face >>> of change, but I suppose that situation is almost inevitable since I >>> can't crystal-ball what changes might be coming along next week and >>> its probably folly to try. XML changes that dynamic, but not >>> completely. >>> >>> I have been having this internal debate about, .. if I concede I'm >>> going to have a relational database then should its design be derived >>> from the XML schema or should the XML schema change to accomodate the >>> database, indeed one of the Solution Designers on this has already >>> indicated a desire to 'flatten' the XML schema (although I have to say >>> I disagree that it is necessary). I have some degree of opportunity to >>> change the XML schema (although messages >>> are received from external sources, within reason, I can transform >>> them into any 'shape' I like so long as thats a loss-less exchange). >>> The database is green field so it can be any shape, but clearly some >>> designs are going to lend themsleves better than others to XML mapping >>> I would have thought ? >>> >>> Surely there are some structures in XML that don't map >>> straight-forwardly. Ted Neward called this the 'last mile' (a familiar >>> term to us all I'm sure), where the illusion of a high fidelity >>> solution draws us in, and indeed 80%+ appears to go quite well, but >>> that last few % hold a disproportiate cost and increasing complexity >>> (but you don't realise that until late on at which point some are >>> going to object to a rethink). I want to know where that 'last mile' >>> lives so I can try and avoid it ! >>> >>> Fraser. >>> >>> 2009/11/2 Jim Tivy <jimt@bluestream.com>: >>>> Fraser >>>> >>>> I am not entirely hearing firm commitment that you plan to establish an >>> RDB >>>> schema and make it the driving schema.  In other words, what this would >>> mean >>>> is that data elements cannot be put into the RDB unless they exist in > the >>>> RDB schema.  For example, if some new data elements show up in some >>> external >>>> XML to be imported then the DBA decides whether to allow them into the >>>> appropriate RDB column or not, or drop them for the time being. >>>> >>>> Another option (from the infinite number) would be to let the XML schema >>>> generate the RDB schema and the mapping code.  For your application >>>> programmers using SQL on the RDB this would likely lead to gagging and >>>> hacking and an "out of body experience"  This is not something I would >>>> recommend and if this is what you want then get a database that supports >>>> XQuery and retrain your developers. >>>> >>>> But I think you have to choose between these two - the first being what >> it >>>> sounds like you want - then work backwards from that decision. >>>> >>>> Jim >>>> >>>> -----Original Message----- >>>> From: Fraser Goffin [mailto:goffinf@googlemail.com] >>>> Sent: Monday, November 02, 2009 12:22 PM >>>> To: xml-dev@lists.xml.org >>>> Subject: Re: [xml-dev] Shredding XML >>>> >>>> Yes Jim, that is spot on. >>>> >>>> Whilst there has been much discussion thus far on the technolgies and >>>> techniques of getting data out of the database (and that has been >>>> interesting), the programming for doing so are 'bread and butter' to >>>> our mainframe Cobol and Sapiens guys, so thats not really my problem. >>>> >>>> Mine is the task of getting the data from a fairly complex XML content >>>> model into an appropriately factored relational database. The design >>>> of that database is 'green field' but (and thanks to many on this >>>> thread who have posted related papers) this may not be as easy at it >>>> might at first appear, what with impedence mismatches here there and >>>> everywhere ;-) >>>> >>>> Its also the case that the XML data doesn't contain enough data >>>> inherently to represent primary or foreign key values for all of the >>>> relationships that are likely to arise. In some cases I MAY be >>>> permitted to generate them myself (say using a UUID) as I 'walk' the >>>> XML, in other cases I MAY be required to get the database to provide >>>> the value(s), not sure yet. The later may increase the complexity >>>> somewhat (sidenote: our DBAs don't allow stored procs (don't ask)  so >>>> I'm going to be doing whole bunches of INSERTs as part of the >>>> tree-walk I suspect) >>>> >>>> I'm really interested in the gotchas and best practices. Some have >>>> already been mentioned like the fact that the XML schema may define >>>> optional items and unrestricted length facets and such like. Others >>>> I've seen in reading talk about the mis-match of identity approaches >>>> (although this was talking primarily about OO/Relational mapping but >>>> the idea is similar I suspect). This could be important, since some >>>> messages received may 'relate' to others already loaded and, given >>>> what I said about not having all of the data in the XML to form all of >>>> the keys, this might be a significant problem. >>>> >>>> It is my intention to look into other options (we have recently >>>> acquired DB2 v9 which includes pureXML) but as is so often the case, >>>> the immediate project delivery pressures won't allow it. The PM is >>>> very nervous about using any new tech, perhaps justifiably, but my >>>> sense of unease is more to do with the perhaps misplaced assumption >>>> that 'tried and tested' tech like relational databases will always >>>> provide a workable solution, imho sometimes they actually represent >>>> the most significant constraint. >>>> >>>> So yes, back to the actual problem. How to come up with a database >>>> design that provides the capability of staging the shredded XML in a >>>> reasonable efficient manner and enables it to be loaded from XML >>>> instances received, again efficiently (ideally without 100's of tables >>>> and joins to negotiate). As far as efficiency of storage, well that >>>> MAY be a concern although perhaps not a huge one so long as the Db >>>> doesn't bloat up too much if normalisation is preferred over extra >>>> tables. >>>> >>>> Please add your thoughts and suggestions and experiences as you are >>>> able. Nothing is too trivial (or rude) to mention (i.e. if you want to >>>> say don't do this if you want to keep your sanity, thats ok). >>>> >>>> regards >>>> >>>> Fraser. >>>> >>>> I'm >>>> >>>> >>>> 2009/11/1 Jim Tivy <jimt@bluestream.com>: >>>>> Interesting post, but I am not sure that "now is the time to talk of >> many >>>>> things". >>>>> >>>>> Let me try to focus: >>>>> >>>>> Proper software execution comes from the choice of appropriate >>>>> actions/technologies to match the driving requirements.  But more >>>>> importantly, the greatest Wisdom, is to frame the driving requirements >>>>> correctly before "going off half cocked" or doing something that is >>>>> unnecessary and unwarranted. >>>>> >>>>> So lets start by framing the requirements again: >>>>> >>>>> Fraser Gofin wrote: >>>>> >>>>> " >>>>> The basics are we receive XML messages from an external trading partner >>>> and >>>>> process those messages, enriching and routing to a number of internal >>>>> subscriber applications. One of these applications is MI and the deal >>> here >>>>> is that they want the data to been put into a relational database so >> that >>>>> they can create a number of interfaces 'files' which are sent to still >>>> more >>>>> applications. >>>>> " >>>>> >>>>> OR >>>>> >>>>> " >>>>> I am mainly interested in the process of LOADING XML data to a database >>>>> rather than extracting (at least for the purposes of this discussion). >>>>> " >>>>> >>>>> It is possible that the "mother persistent application datamodel" is >>>>> contained in the relational database in all its normalized glory.  If >> so, >>>>> then, "processing the messages" is simply a "data import" operation. >  So >>>> the >>>>> question is, how do I get XML X* to tables T*.  It would strike me that >>>> lots >>>>> of people are doing this.  Are there common techniques and technologies >>>> for >>>>> doing this import? >>>>> >>>>> Fraser, is that a proper framing of the question/requirements? >>>>> >>>>> Jim >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Petite Abeille [mailto:petite.abeille@gmail.com] >>>>> Sent: Sunday, November 01, 2009 9:56 AM >>>>> To: xml-dev@lists.xml.org >>>>> Subject: Re: [xml-dev] Shredding XML >>>>> >>>>> >>>>> On Oct 29, 2009, at 10:20 PM, Fraser Goffin wrote: >>>>> >>>>>> opinions on the subject of decomposing XML into relational databases >>>>> >>>>> Outside of the most trivial case, this is a major PITA of the same >>>>> epic proportion as the object-relational one: >>>>> >>>>> >>> > http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx >>>>> >>>>> Good luck. >>>>> >>>>> >>>>> >>>>> _______________________________________________________________________ >>>>> >>>>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >>>>> to support XML implementation and development. To minimize >>>>> spam in the archives, you must subscribe before posting. >>>>> >>>>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >>>>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >>>>> subscribe: xml-dev-subscribe@lists.xml.org >>>>> List archive: http://lists.xml.org/archives/xml-dev/ >>>>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________________________________ >>>>> >>>>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >>>>> to support XML implementation and development. To minimize >>>>> spam in the archives, you must subscribe before posting. >>>>> >>>>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >>>>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >>>>> subscribe: xml-dev-subscribe@lists.xml.org >>>>> List archive: http://lists.xml.org/archives/xml-dev/ >>>>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >>>>> >>>>> >>>> >>>> _______________________________________________________________________ >>>> >>>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >>>> to support XML implementation and development. To minimize >>>> spam in the archives, you must subscribe before posting. >>>> >>>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >>>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >>>> subscribe: xml-dev-subscribe@lists.xml.org >>>> List archive: http://lists.xml.org/archives/xml-dev/ >>>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >>>> >>>> >>>> >>>> >>> >>> _______________________________________________________________________ >>> >>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >>> to support XML implementation and development. To minimize >>> spam in the archives, you must subscribe before posting. >>> >>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >>> subscribe: xml-dev-subscribe@lists.xml.org >>> List archive: http://lists.xml.org/archives/xml-dev/ >>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >>> >>> >>> >>> >> >> _______________________________________________________________________ >> >> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >> to support XML implementation and development. To minimize >> spam in the archives, you must subscribe before posting. >> >> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >> subscribe: xml-dev-subscribe@lists.xml.org >> List archive: http://lists.xml.org/archives/xml-dev/ >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >> >> >> >> > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > > > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306038.html Fraser Often XML coming in reflects one hierarchy of the data - for example invoice header and details - for example, where each invoice is a customer transaction at a CoffeeHouse Chain. These incoming hierarchies can have redundant information - for example the address of a customer as stated in each invoice. If you need to report on this data in a different hiearchy, first you need to define an appropriate RDB application data model and then import carefully into it to remove redudancy, normalize the data into respective entities (tables) and generally protect and enforce the quality of data in the database. Then you can acurately report on the data where the output of the report reflects a different hierarchy than the incoming Xml data - say, total product sales of product latte in January by City by Store. In this way, the reports you need out will carry requirements for your RDB application data model. Not sure what you mean by "interface files"? Jim -----Original Message----- From: Fraser Goffin [mailto:goffinf@googlemail.com] Sent: Wednesday, November 04, 2009 8:20 AM To: xml-dev@lists.xml.org Subject: Re: [xml-dev] Shredding XML I don't know the full detail of the interface files that will be produced from this store, but its probably safe to assume that these will need to model the data with multiple hierarchies and groupings. Whats driving this line of thought ? Fraser. 2009/11/3 Jim Tivy <jimt@bluestream.com>: > do they need to produce reports that present the information in > multiple hierarchial ways?  It might be invoices within a day or Lattes sold > within City within Province. > > -----Original Message----- > From: Fraser Goffin [mailto:goffinf@googlemail.com] > Sent: Tuesday, November 03, 2009 1:41 AM > To: xml-dev@lists.xml.org > Subject: Re: [xml-dev] Shredding XML > >> Do your applications that use the relational database need to update > > Thats a difficult one. As far as producing up-stream interfaces, no, > they are created just by selecting from the database. > > However, as I mentioned (lost in the detail) earlier, messages > received will have a relationship to existing records. I'm not at all > convinced that update will be possible because not all of the keys > will be available in the message received. Some form of 'fuzzy' > matching may be possible in some case, for example, if I receive a new > address then the 1st line + PostCode + the relationship of this > address to something else may be sufficient. > > It might be the case that we have to consider time based snap-shots, > i.e. the 'state' of a collection of data at a point in time. Not sure > yet, its one of those areas of difficulty that probably doesn't change > much whether I use relational of native XML stores. > > At present the primary purpose of the database is for retreival, i.e. > its NOT an operational store, its for MI, so optimiastions for read > rather than update are appropriate. > >> do they need to produce reports that present the information in multiple > ways > > Yes. > > Fraser. > > 2009/11/3 Jim Tivy <jimt@bluestream.com>: >> Do your applications that use the relational database need to update and > do >> they need to produce reports that present the information in multiple ways >> hierarchial ways?  This may suggest whether your database needs to be >> normalized (approaching 3rd Normal form)? >> >> -----Original Message----- >> From: Fraser Goffin [mailto:goffinf@googlemail.com] >> Sent: Monday, November 02, 2009 3:31 PM >> To: xml-dev@lists.xml.org >> Subject: Re: [xml-dev] Shredding XML >> >> Hi Jim, >> >> thats interesting ... which should be the 'driving' schema, XML or Db ? >> >> I guess I've been somewhat tiptoe'ing around this one. >> >> I should admit my bias if its not already apparent. I work mainly in >> the SOA integration space and since XML is the primary exchange format >> and XML schema does a reasonable job as the type system, I favour >> processing XML as .. well XML ... whilst I understand the argument >> around leveraging existing technologies and skillset .. often-times >> this is little more than protectionism and continually [de]composing >> from XML to objects then to CopyLibs and then to relational just seems >> unnecessary a lot of the time (sorry - soap box over).  But of course >> the whole world isn't XML and just like most other large organisations >> the vast majority of our processing capability and data isn't and >> probably never will be ... I have no issue with that. >> >> On the one hand it is the end product that drives the design (even if >> that design has a relatively short shelf-life ... but hey, we all do >> agile right). In that case it is definately the Database schema that >> prevails from the pure delivery point of view, since this is the >> desired source for the staging area from which to produce interface >> files for upstream applications. At present there appears to be no >> possiblility of revisiting that choice. At the same time, I don't want >> to 'paint myself into a corner' or promote this as an exemplar for all >> future approaches (unless it turns out that way :-) >> >> My unease is around the brittleness of the database schema in the face >> of change, but I suppose that situation is almost inevitable since I >> can't crystal-ball what changes might be coming along next week and >> its probably folly to try. XML changes that dynamic, but not >> completely. >> >> I have been having this internal debate about, .. if I concede I'm >> going to have a relational database then should its design be derived >> from the XML schema or should the XML schema change to accomodate the >> database, indeed one of the Solution Designers on this has already >> indicated a desire to 'flatten' the XML schema (although I have to say >> I disagree that it is necessary). I have some degree of opportunity to >> change the XML schema (although messages >> are received from external sources, within reason, I can transform >> them into any 'shape' I like so long as thats a loss-less exchange). >> The database is green field so it can be any shape, but clearly some >> designs are going to lend themsleves better than others to XML mapping >> I would have thought ? >> >> Surely there are some structures in XML that don't map >> straight-forwardly. Ted Neward called this the 'last mile' (a familiar >> term to us all I'm sure), where the illusion of a high fidelity >> solution draws us in, and indeed 80%+ appears to go quite well, but >> that last few % hold a disproportiate cost and increasing complexity >> (but you don't realise that until late on at which point some are >> going to object to a rethink). I want to know where that 'last mile' >> lives so I can try and avoid it ! >> >> Fraser. >> >> 2009/11/2 Jim Tivy <jimt@bluestream.com>: >>> Fraser >>> >>> I am not entirely hearing firm commitment that you plan to establish an >> RDB >>> schema and make it the driving schema.  In other words, what this would >> mean >>> is that data elements cannot be put into the RDB unless they exist in the >>> RDB schema.  For example, if some new data elements show up in some >> external >>> XML to be imported then the DBA decides whether to allow them into the >>> appropriate RDB column or not, or drop them for the time being. >>> >>> Another option (from the infinite number) would be to let the XML schema >>> generate the RDB schema and the mapping code.  For your application >>> programmers using SQL on the RDB this would likely lead to gagging and >>> hacking and an "out of body experience"  This is not something I would >>> recommend and if this is what you want then get a database that supports >>> XQuery and retrain your developers. >>> >>> But I think you have to choose between these two - the first being what > it >>> sounds like you want - then work backwards from that decision. >>> >>> Jim >>> >>> -----Original Message----- >>> From: Fraser Goffin [mailto:goffinf@googlemail.com] >>> Sent: Monday, November 02, 2009 12:22 PM >>> To: xml-dev@lists.xml.org >>> Subject: Re: [xml-dev] Shredding XML >>> >>> Yes Jim, that is spot on. >>> >>> Whilst there has been much discussion thus far on the technolgies and >>> techniques of getting data out of the database (and that has been >>> interesting), the programming for doing so are 'bread and butter' to >>> our mainframe Cobol and Sapiens guys, so thats not really my problem. >>> >>> Mine is the task of getting the data from a fairly complex XML content >>> model into an appropriately factored relational database. The design >>> of that database is 'green field' but (and thanks to many on this >>> thread who have posted related papers) this may not be as easy at it >>> might at first appear, what with impedence mismatches here there and >>> everywhere ;-) >>> >>> Its also the case that the XML data doesn't contain enough data >>> inherently to represent primary or foreign key values for all of the >>> relationships that are likely to arise. In some cases I MAY be >>> permitted to generate them myself (say using a UUID) as I 'walk' the >>> XML, in other cases I MAY be required to get the database to provide >>> the value(s), not sure yet. The later may increase the complexity >>> somewhat (sidenote: our DBAs don't allow stored procs (don't ask)  so >>> I'm going to be doing whole bunches of INSERTs as part of the >>> tree-walk I suspect) >>> >>> I'm really interested in the gotchas and best practices. Some have >>> already been mentioned like the fact that the XML schema may define >>> optional items and unrestricted length facets and such like. Others >>> I've seen in reading talk about the mis-match of identity approaches >>> (although this was talking primarily about OO/Relational mapping but >>> the idea is similar I suspect). This could be important, since some >>> messages received may 'relate' to others already loaded and, given >>> what I said about not having all of the data in the XML to form all of >>> the keys, this might be a significant problem. >>> >>> It is my intention to look into other options (we have recently >>> acquired DB2 v9 which includes pureXML) but as is so often the case, >>> the immediate project delivery pressures won't allow it. The PM is >>> very nervous about using any new tech, perhaps justifiably, but my >>> sense of unease is more to do with the perhaps misplaced assumption >>> that 'tried and tested' tech like relational databases will always >>> provide a workable solution, imho sometimes they actually represent >>> the most significant constraint. >>> >>> So yes, back to the actual problem. How to come up with a database >>> design that provides the capability of staging the shredded XML in a >>> reasonable efficient manner and enables it to be loaded from XML >>> instances received, again efficiently (ideally without 100's of tables >>> and joins to negotiate). As far as efficiency of storage, well that >>> MAY be a concern although perhaps not a huge one so long as the Db >>> doesn't bloat up too much if normalisation is preferred over extra >>> tables. >>> >>> Please add your thoughts and suggestions and experiences as you are >>> able. Nothing is too trivial (or rude) to mention (i.e. if you want to >>> say don't do this if you want to keep your sanity, thats ok). >>> >>> regards >>> >>> Fraser. >>> >>> I'm >>> >>> >>> 2009/11/1 Jim Tivy <jimt@bluestream.com>: >>>> Interesting post, but I am not sure that "now is the time to talk of > many >>>> things". >>>> >>>> Let me try to focus: >>>> >>>> Proper software execution comes from the choice of appropriate >>>> actions/technologies to match the driving requirements.  But more >>>> importantly, the greatest Wisdom, is to frame the driving requirements >>>> correctly before "going off half cocked" or doing something that is >>>> unnecessary and unwarranted. >>>> >>>> So lets start by framing the requirements again: >>>> >>>> Fraser Gofin wrote: >>>> >>>> " >>>> The basics are we receive XML messages from an external trading partner >>> and >>>> process those messages, enriching and routing to a number of internal >>>> subscriber applications. One of these applications is MI and the deal >> here >>>> is that they want the data to been put into a relational database so > that >>>> they can create a number of interfaces 'files' which are sent to still >>> more >>>> applications. >>>> " >>>> >>>> OR >>>> >>>> " >>>> I am mainly interested in the process of LOADING XML data to a database >>>> rather than extracting (at least for the purposes of this discussion). >>>> " >>>> >>>> It is possible that the "mother persistent application datamodel" is >>>> contained in the relational database in all its normalized glory.  If > so, >>>> then, "processing the messages" is simply a "data import" operation.  So >>> the >>>> question is, how do I get XML X* to tables T*.  It would strike me that >>> lots >>>> of people are doing this.  Are there common techniques and technologies >>> for >>>> doing this import? >>>> >>>> Fraser, is that a proper framing of the question/requirements? >>>> >>>> Jim >>>> >>>> >>>> -----Original Message----- >>>> From: Petite Abeille [mailto:petite.abeille@gmail.com] >>>> Sent: Sunday, November 01, 2009 9:56 AM >>>> To: xml-dev@lists.xml.org >>>> Subject: Re: [xml-dev] Shredding XML >>>> >>>> >>>> On Oct 29, 2009, at 10:20 PM, Fraser Goffin wrote: >>>> >>>>> opinions on the subject of decomposing XML into relational databases >>>> >>>> Outside of the most trivial case, this is a major PITA of the same >>>> epic proportion as the object-relational one: >>>> >>>> >> http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx >>>> >>>> Good luck. >>>> >>>> >>>> >>>> _______________________________________________________________________ >>>> >>>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >>>> to support XML implementation and development. To minimize >>>> spam in the archives, you must subscribe before posting. >>>> >>>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >>>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >>>> subscribe: xml-dev-subscribe@lists.xml.org >>>> List archive: http://lists.xml.org/archives/xml-dev/ >>>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >>>> >>>> >>>> >>>> >>>> _______________________________________________________________________ >>>> >>>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >>>> to support XML implementation and development. To minimize >>>> spam in the archives, you must subscribe before posting. >>>> >>>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >>>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >>>> subscribe: xml-dev-subscribe@lists.xml.org >>>> List archive: http://lists.xml.org/archives/xml-dev/ >>>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >>>> >>>> >>> >>> _______________________________________________________________________ >>> >>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >>> to support XML implementation and development. To minimize >>> spam in the archives, you must subscribe before posting. >>> >>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >>> subscribe: xml-dev-subscribe@lists.xml.org >>> List archive: http://lists.xml.org/archives/xml-dev/ >>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >>> >>> >>> >>> >> >> _______________________________________________________________________ >> >> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >> to support XML implementation and development. To minimize >> spam in the archives, you must subscribe before posting. >> >> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >> subscribe: xml-dev-subscribe@lists.xml.org >> List archive: http://lists.xml.org/archives/xml-dev/ >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >> >> >> >> > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > > > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306029.html I don't know the full detail of the interface files that will be produced from this store, but its probably safe to assume that these will need to model the data with multiple hierarchies and groupings. Whats driving this line of thought ? Fraser. 2009/11/3 Jim Tivy <jimt@bluestream.com>: > do they need to produce reports that present the information in > multiple hierarchial ways?  It might be invoices within a day or Lattes sold > within City within Province. > > -----Original Message----- > From: Fraser Goffin [mailto:goffinf@googlemail.com] > Sent: Tuesday, November 03, 2009 1:41 AM > To: xml-dev@lists.xml.org > Subject: Re: [xml-dev] Shredding XML > >> Do your applications that use the relational database need to update > > Thats a difficult one. As far as producing up-stream interfaces, no, > they are created just by selecting from the database. > > However, as I mentioned (lost in the detail) earlier, messages > received will have a relationship to existing records. I'm not at all > convinced that update will be possible because not all of the keys > will be available in the message received. Some form of 'fuzzy' > matching may be possible in some case, for example, if I receive a new > address then the 1st line + PostCode + the relationship of this > address to something else may be sufficient. > > It might be the case that we have to consider time based snap-shots, > i.e. the 'state' of a collection of data at a point in time. Not sure > yet, its one of those areas of difficulty that probably doesn't change > much whether I use relational of native XML stores. > > At present the primary purpose of the database is for retreival, i.e. > its NOT an operational store, its for MI, so optimiastions for read > rather than update are appropriate. > >> do they need to produce reports that present the information in multiple > ways > > Yes. > > Fraser. > > 2009/11/3 Jim Tivy <jimt@bluestream.com>: >> Do your applications that use the relational database need to update and > do >> they need to produce reports that present the information in multiple ways >> hierarchial ways?  This may suggest whether your database needs to be >> normalized (approaching 3rd Normal form)? >> >> -----Original Message----- >> From: Fraser Goffin [mailto:goffinf@googlemail.com] >> Sent: Monday, November 02, 2009 3:31 PM >> To: xml-dev@lists.xml.org >> Subject: Re: [xml-dev] Shredding XML >> >> Hi Jim, >> >> thats interesting ... which should be the 'driving' schema, XML or Db ? >> >> I guess I've been somewhat tiptoe'ing around this one. >> >> I should admit my bias if its not already apparent. I work mainly in >> the SOA integration space and since XML is the primary exchange format >> and XML schema does a reasonable job as the type system, I favour >> processing XML as .. well XML ... whilst I understand the argument >> around leveraging existing technologies and skillset .. often-times >> this is little more than protectionism and continually [de]composing >> from XML to objects then to CopyLibs and then to relational just seems >> unnecessary a lot of the time (sorry - soap box over).  But of course >> the whole world isn't XML and just like most other large organisations >> the vast majority of our processing capability and data isn't and >> probably never will be ... I have no issue with that. >> >> On the one hand it is the end product that drives the design (even if >> that design has a relatively short shelf-life ... but hey, we all do >> agile right). In that case it is definately the Database schema that >> prevails from the pure delivery point of view, since this is the >> desired source for the staging area from which to produce interface >> files for upstream applications. At present there appears to be no >> possiblility of revisiting that choice. At the same time, I don't want >> to 'paint myself into a corner' or promote this as an exemplar for all >> future approaches (unless it turns out that way :-) >> >> My unease is around the brittleness of the database schema in the face >> of change, but I suppose that situation is almost inevitable since I >> can't crystal-ball what changes might be coming along next week and >> its probably folly to try. XML changes that dynamic, but not >> completely. >> >> I have been having this internal debate about, .. if I concede I'm >> going to have a relational database then should its design be derived >> from the XML schema or should the XML schema change to accomodate the >> database, indeed one of the Solution Designers on this has already >> indicated a desire to 'flatten' the XML schema (although I have to say >> I disagree that it is necessary). I have some degree of opportunity to >> change the XML schema (although messages >> are received from external sources, within reason, I can transform >> them into any 'shape' I like so long as thats a loss-less exchange). >> The database is green field so it can be any shape, but clearly some >> designs are going to lend themsleves better than others to XML mapping >> I would have thought ? >> >> Surely there are some structures in XML that don't map >> straight-forwardly. Ted Neward called this the 'last mile' (a familiar >> term to us all I'm sure), where the illusion of a high fidelity >> solution draws us in, and indeed 80%+ appears to go quite well, but >> that last few % hold a disproportiate cost and increasing complexity >> (but you don't realise that until late on at which point some are >> going to object to a rethink). I want to know where that 'last mile' >> lives so I can try and avoid it ! >> >> Fraser. >> >> 2009/11/2 Jim Tivy <jimt@bluestream.com>: >>> Fraser >>> >>> I am not entirely hearing firm commitment that you plan to establish an >> RDB >>> schema and make it the driving schema.  In other words, what this would >> mean >>> is that data elements cannot be put into the RDB unless they exist in the >>> RDB schema.  For example, if some new data elements show up in some >> external >>> XML to be imported then the DBA decides whether to allow them into the >>> appropriate RDB column or not, or drop them for the time being. >>> >>> Another option (from the infinite number) would be to let the XML schema >>> generate the RDB schema and the mapping code.  For your application >>> programmers using SQL on the RDB this would likely lead to gagging and >>> hacking and an "out of body experience"  This is not something I would >>> recommend and if this is what you want then get a database that supports >>> XQuery and retrain your developers. >>> >>> But I think you have to choose between these two - the first being what > it >>> sounds like you want - then work backwards from that decision. >>> >>> Jim >>> >>> -----Original Message----- >>> From: Fraser Goffin [mailto:goffinf@googlemail.com] >>> Sent: Monday, November 02, 2009 12:22 PM >>> To: xml-dev@lists.xml.org >>> Subject: Re: [xml-dev] Shredding XML >>> >>> Yes Jim, that is spot on. >>> >>> Whilst there has been much discussion thus far on the technolgies and >>> techniques of getting data out of the database (and that has been >>> interesting), the programming for doing so are 'bread and butter' to >>> our mainframe Cobol and Sapiens guys, so thats not really my problem. >>> >>> Mine is the task of getting the data from a fairly complex XML content >>> model into an appropriately factored relational database. The design >>> of that database is 'green field' but (and thanks to many on this >>> thread who have posted related papers) this may not be as easy at it >>> might at first appear, what with impedence mismatches here there and >>> everywhere ;-) >>> >>> Its also the case that the XML data doesn't contain enough data >>> inherently to represent primary or foreign key values for all of the >>> relationships that are likely to arise. In some cases I MAY be >>> permitted to generate them myself (say using a UUID) as I 'walk' the >>> XML, in other cases I MAY be required to get the database to provide >>> the value(s), not sure yet. The later may increase the complexity >>> somewhat (sidenote: our DBAs don't allow stored procs (don't ask)  so >>> I'm going to be doing whole bunches of INSERTs as part of the >>> tree-walk I suspect) >>> >>> I'm really interested in the gotchas and best practices. Some have >>> already been mentioned like the fact that the XML schema may define >>> optional items and unrestricted length facets and such like. Others >>> I've seen in reading talk about the mis-match of identity approaches >>> (although this was talking primarily about OO/Relational mapping but >>> the idea is similar I suspect). This could be important, since some >>> messages received may 'relate' to others already loaded and, given >>> what I said about not having all of the data in the XML to form all of >>> the keys, this might be a significant problem. >>> >>> It is my intention to look into other options (we have recently >>> acquired DB2 v9 which includes pureXML) but as is so often the case, >>> the immediate project delivery pressures won't allow it. The PM is >>> very nervous about using any new tech, perhaps justifiably, but my >>> sense of unease is more to do with the perhaps misplaced assumption >>> that 'tried and tested' tech like relational databases will always >>> provide a workable solution, imho sometimes they actually represent >>> the most significant constraint. >>> >>> So yes, back to the actual problem. How to come up with a database >>> design that provides the capability of staging the shredded XML in a >>> reasonable efficient manner and enables it to be loaded from XML >>> instances received, again efficiently (ideally without 100's of tables >>> and joins to negotiate). As far as efficiency of storage, well that >>> MAY be a concern although perhaps not a huge one so long as the Db >>> doesn't bloat up too much if normalisation is preferred over extra >>> tables. >>> >>> Please add your thoughts and suggestions and experiences as you are >>> able. Nothing is too trivial (or rude) to mention (i.e. if you want to >>> say don't do this if you want to keep your sanity, thats ok). >>> >>> regards >>> >>> Fraser. >>> >>> I'm >>> >>> >>> 2009/11/1 Jim Tivy <jimt@bluestream.com>: >>>> Interesting post, but I am not sure that "now is the time to talk of > many >>>> things". >>>> >>>> Let me try to focus: >>>> >>>> Proper software execution comes from the choice of appropriate >>>> actions/technologies to match the driving requirements.  But more >>>> importantly, the greatest Wisdom, is to frame the driving requirements >>>> correctly before "going off half cocked" or doing something that is >>>> unnecessary and unwarranted. >>>> >>>> So lets start by framing the requirements again: >>>> >>>> Fraser Gofin wrote: >>>> >>>> " >>>> The basics are we receive XML messages from an external trading partner >>> and >>>> process those messages, enriching and routing to a number of internal >>>> subscriber applications. One of these applications is MI and the deal >> here >>>> is that they want the data to been put into a relational database so > that >>>> they can create a number of interfaces 'files' which are sent to still >>> more >>>> applications. >>>> " >>>> >>>> OR >>>> >>>> " >>>> I am mainly interested in the process of LOADING XML data to a database >>>> rather than extracting (at least for the purposes of this discussion). >>>> " >>>> >>>> It is possible that the "mother persistent application datamodel" is >>>> contained in the relational database in all its normalized glory.  If > so, >>>> then, "processing the messages" is simply a "data import" operation.  So >>> the >>>> question is, how do I get XML X* to tables T*.  It would strike me that >>> lots >>>> of people are doing this.  Are there common techniques and technologies >>> for >>>> doing this import? >>>> >>>> Fraser, is that a proper framing of the question/requirements? >>>> >>>> Jim >>>> >>>> >>>> -----Original Message----- >>>> From: Petite Abeille [mailto:petite.abeille@gmail.com] >>>> Sent: Sunday, November 01, 2009 9:56 AM >>>> To: xml-dev@lists.xml.org >>>> Subject: Re: [xml-dev] Shredding XML >>>> >>>> >>>> On Oct 29, 2009, at 10:20 PM, Fraser Goffin wrote: >>>> >>>>> opinions on the subject of decomposing XML into relational databases >>>> >>>> Outside of the most trivial case, this is a major PITA of the same >>>> epic proportion as the object-relational one: >>>> >>>> >> http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx >>>> >>>> Good luck. >>>> >>>> >>>> >>>> _______________________________________________________________________ >>>> >>>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >>>> to support XML implementation and development. To minimize >>>> spam in the archives, you must subscribe before posting. >>>> >>>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >>>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >>>> subscribe: xml-dev-subscribe@lists.xml.org >>>> List archive: http://lists.xml.org/archives/xml-dev/ >>>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >>>> >>>> >>>> >>>> >>>> _______________________________________________________________________ >>>> >>>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >>>> to support XML implementation and development. To minimize >>>> spam in the archives, you must subscribe before posting. >>>> >>>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >>>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >>>> subscribe: xml-dev-subscribe@lists.xml.org >>>> List archive: http://lists.xml.org/archives/xml-dev/ >>>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >>>> >>>> >>> >>> _______________________________________________________________________ >>> >>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >>> to support XML implementation and development. To minimize >>> spam in the archives, you must subscribe before posting. >>> >>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >>> subscribe: xml-dev-subscribe@lists.xml.org >>> List archive: http://lists.xml.org/archives/xml-dev/ >>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >>> >>> >>> >>> >> >> _______________________________________________________________________ >> >> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >> to support XML implementation and development. To minimize >> spam in the archives, you must subscribe before posting. >> >> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >> subscribe: xml-dev-subscribe@lists.xml.org >> List archive: http://lists.xml.org/archives/xml-dev/ >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >> >> >> >> > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > > > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000306020.html Data Management Solutions is pleased to announce MXV - a Model-driven XML Vocabulary design solution: Find out how your own UML class model can be implemented in a style very similar to OASIS UBL NDR 2.0 and how to derive your own W3C XML Library and Document Schemas from UML. Two implementation options: + Entirely manual, or + Use a popular modelling tool, and optionally deploy MXV Productivity Tools to - perform NDR compliance checks on UML and XML Schema models - synchronise XML Library Schema models with UML master model - generate W3C Library and Document Schemas - generate OASIS Genericode, Context Value Association and ISO Schematron skeleton files (for optional Value Validation) - generate document schema and value validation documentation - assemble shippable delivery packages for selected document schemas - perform version management, version compares - perform impact analysis from UML-to-XML Schema - and many more features Data Management Solutions is pleased to share details of this portable, industry-independent, yet customisable XML Schema design solution at http://www.d-m-s.co.nz/serv_xmlschema.htm Please feel free to contact me with any queries you may have. Regards, Juerg Tschumperlin Data Management Solutions Wellington, New Zealand www.d-m-s.co.nz cc: XML-dev, CLR-dev, UBL-dev]]> http://www.altova.com/list/xml-dev/200911/msg1000305979.html do they need to produce reports that present the information in multiple hierarchial ways? It might be invoices within a day or Lattes sold within City within Province. -----Original Message----- From: Fraser Goffin [mailto:goffinf@googlemail.com] Sent: Tuesday, November 03, 2009 1:41 AM To: xml-dev@lists.xml.org Subject: Re: [xml-dev] Shredding XML > Do your applications that use the relational database need to update Thats a difficult one. As far as producing up-stream interfaces, no, they are created just by selecting from the database. However, as I mentioned (lost in the detail) earlier, messages received will have a relationship to existing records. I'm not at all convinced that update will be possible because not all of the keys will be available in the message received. Some form of 'fuzzy' matching may be possible in some case, for example, if I receive a new address then the 1st line + PostCode + the relationship of this address to something else may be sufficient. It might be the case that we have to consider time based snap-shots, i.e. the 'state' of a collection of data at a point in time. Not sure yet, its one of those areas of difficulty that probably doesn't change much whether I use relational of native XML stores. At present the primary purpose of the database is for retreival, i.e. its NOT an operational store, its for MI, so optimiastions for read rather than update are appropriate. > do they need to produce reports that present the information in multiple ways Yes. Fraser. 2009/11/3 Jim Tivy <jimt@bluestream.com>: > Do your applications that use the relational database need to update and do > they need to produce reports that present the information in multiple ways > hierarchial ways?  This may suggest whether your database needs to be > normalized (approaching 3rd Normal form)? > > -----Original Message----- > From: Fraser Goffin [mailto:goffinf@googlemail.com] > Sent: Monday, November 02, 2009 3:31 PM > To: xml-dev@lists.xml.org > Subject: Re: [xml-dev] Shredding XML > > Hi Jim, > > thats interesting ... which should be the 'driving' schema, XML or Db ? > > I guess I've been somewhat tiptoe'ing around this one. > > I should admit my bias if its not already apparent. I work mainly in > the SOA integration space and since XML is the primary exchange format > and XML schema does a reasonable job as the type system, I favour > processing XML as .. well XML ... whilst I understand the argument > around leveraging existing technologies and skillset .. often-times > this is little more than protectionism and continually [de]composing > from XML to objects then to CopyLibs and then to relational just seems > unnecessary a lot of the time (sorry - soap box over).  But of course > the whole world isn't XML and just like most other large organisations > the vast majority of our processing capability and data isn't and > probably never will be ... I have no issue with that. > > On the one hand it is the end product that drives the design (even if > that design has a relatively short shelf-life ... but hey, we all do > agile right). In that case it is definately the Database schema that > prevails from the pure delivery point of view, since this is the > desired source for the staging area from which to produce interface > files for upstream applications. At present there appears to be no > possiblility of revisiting that choice. At the same time, I don't want > to 'paint myself into a corner' or promote this as an exemplar for all > future approaches (unless it turns out that way :-) > > My unease is around the brittleness of the database schema in the face > of change, but I suppose that situation is almost inevitable since I > can't crystal-ball what changes might be coming along next week and > its probably folly to try. XML changes that dynamic, but not > completely. > > I have been having this internal debate about, .. if I concede I'm > going to have a relational database then should its design be derived > from the XML schema or should the XML schema change to accomodate the > database, indeed one of the Solution Designers on this has already > indicated a desire to 'flatten' the XML schema (although I have to say > I disagree that it is necessary). I have some degree of opportunity to > change the XML schema (although messages > are received from external sources, within reason, I can transform > them into any 'shape' I like so long as thats a loss-less exchange). > The database is green field so it can be any shape, but clearly some > designs are going to lend themsleves better than others to XML mapping > I would have thought ? > > Surely there are some structures in XML that don't map > straight-forwardly. Ted Neward called this the 'last mile' (a familiar > term to us all I'm sure), where the illusion of a high fidelity > solution draws us in, and indeed 80%+ appears to go quite well, but > that last few % hold a disproportiate cost and increasing complexity > (but you don't realise that until late on at which point some are > going to object to a rethink). I want to know where that 'last mile' > lives so I can try and avoid it ! > > Fraser. > > 2009/11/2 Jim Tivy <jimt@bluestream.com>: >> Fraser >> >> I am not entirely hearing firm commitment that you plan to establish an > RDB >> schema and make it the driving schema.  In other words, what this would > mean >> is that data elements cannot be put into the RDB unless they exist in the >> RDB schema.  For example, if some new data elements show up in some > external >> XML to be imported then the DBA decides whether to allow them into the >> appropriate RDB column or not, or drop them for the time being. >> >> Another option (from the infinite number) would be to let the XML schema >> generate the RDB schema and the mapping code.  For your application >> programmers using SQL on the RDB this would likely lead to gagging and >> hacking and an "out of body experience"  This is not something I would >> recommend and if this is what you want then get a database that supports >> XQuery and retrain your developers. >> >> But I think you have to choose between these two - the first being what it >> sounds like you want - then work backwards from that decision. >> >> Jim >> >> -----Original Message----- >> From: Fraser Goffin [mailto:goffinf@googlemail.com] >> Sent: Monday, November 02, 2009 12:22 PM >> To: xml-dev@lists.xml.org >> Subject: Re: [xml-dev] Shredding XML >> >> Yes Jim, that is spot on. >> >> Whilst there has been much discussion thus far on the technolgies and >> techniques of getting data out of the database (and that has been >> interesting), the programming for doing so are 'bread and butter' to >> our mainframe Cobol and Sapiens guys, so thats not really my problem. >> >> Mine is the task of getting the data from a fairly complex XML content >> model into an appropriately factored relational database. The design >> of that database is 'green field' but (and thanks to many on this >> thread who have posted related papers) this may not be as easy at it >> might at first appear, what with impedence mismatches here there and >> everywhere ;-) >> >> Its also the case that the XML data doesn't contain enough data >> inherently to represent primary or foreign key values for all of the >> relationships that are likely to arise. In some cases I MAY be >> permitted to generate them myself (say using a UUID) as I 'walk' the >> XML, in other cases I MAY be required to get the database to provide >> the value(s), not sure yet. The later may increase the complexity >> somewhat (sidenote: our DBAs don't allow stored procs (don't ask)  so >> I'm going to be doing whole bunches of INSERTs as part of the >> tree-walk I suspect) >> >> I'm really interested in the gotchas and best practices. Some have >> already been mentioned like the fact that the XML schema may define >> optional items and unrestricted length facets and such like. Others >> I've seen in reading talk about the mis-match of identity approaches >> (although this was talking primarily about OO/Relational mapping but >> the idea is similar I suspect). This could be important, since some >> messages received may 'relate' to others already loaded and, given >> what I said about not having all of the data in the XML to form all of >> the keys, this might be a significant problem. >> >> It is my intention to look into other options (we have recently >> acquired DB2 v9 which includes pureXML) but as is so often the case, >> the immediate project delivery pressures won't allow it. The PM is >> very nervous about using any new tech, perhaps justifiably, but my >> sense of unease is more to do with the perhaps misplaced assumption >> that 'tried and tested' tech like relational databases will always >> provide a workable solution, imho sometimes they actually represent >> the most significant constraint. >> >> So yes, back to the actual problem. How to come up with a database >> design that provides the capability of staging the shredded XML in a >> reasonable efficient manner and enables it to be loaded from XML >> instances received, again efficiently (ideally without 100's of tables >> and joins to negotiate). As far as efficiency of storage, well that >> MAY be a concern although perhaps not a huge one so long as the Db >> doesn't bloat up too much if normalisation is preferred over extra >> tables. >> >> Please add your thoughts and suggestions and experiences as you are >> able. Nothing is too trivial (or rude) to mention (i.e. if you want to >> say don't do this if you want to keep your sanity, thats ok). >> >> regards >> >> Fraser. >> >> I'm >> >> >> 2009/11/1 Jim Tivy <jimt@bluestream.com>: >>> Interesting post, but I am not sure that "now is the time to talk of many >>> things". >>> >>> Let me try to focus: >>> >>> Proper software execution comes from the choice of appropriate >>> actions/technologies to match the driving requirements.  But more >>> importantly, the greatest Wisdom, is to frame the driving requirements >>> correctly before "going off half cocked" or doing something that is >>> unnecessary and unwarranted. >>> >>> So lets start by framing the requirements again: >>> >>> Fraser Gofin wrote: >>> >>> " >>> The basics are we receive XML messages from an external trading partner >> and >>> process those messages, enriching and routing to a number of internal >>> subscriber applications. One of these applications is MI and the deal > here >>> is that they want the data to been put into a relational database so that >>> they can create a number of interfaces 'files' which are sent to still >> more >>> applications. >>> " >>> >>> OR >>> >>> " >>> I am mainly interested in the process of LOADING XML data to a database >>> rather than extracting (at least for the purposes of this discussion). >>> " >>> >>> It is possible that the "mother persistent application datamodel" is >>> contained in the relational database in all its normalized glory.  If so, >>> then, "processing the messages" is simply a "data import" operation.  So >> the >>> question is, how do I get XML X* to tables T*.  It would strike me that >> lots >>> of people are doing this.  Are there common techniques and technologies >> for >>> doing this import? >>> >>> Fraser, is that a proper framing of the question/requirements? >>> >>> Jim >>> >>> >>> -----Original Message----- >>> From: Petite Abeille [mailto:petite.abeille@gmail.com] >>> Sent: Sunday, November 01, 2009 9:56 AM >>> To: xml-dev@lists.xml.org >>> Subject: Re: [xml-dev] Shredding XML >>> >>> >>> On Oct 29, 2009, at 10:20 PM, Fraser Goffin wrote: >>> >>>> opinions on the subject of decomposing XML into relational databases >>> >>> Outside of the most trivial case, this is a major PITA of the same >>> epic proportion as the object-relational one: >>> >>> > http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx >>> >>> Good luck. >>> >>> >>> >>> _______________________________________________________________________ >>> >>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >>> to support XML implementation and development. To minimize >>> spam in the archives, you must subscribe before posting. >>> >>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >>> subscribe: xml-dev-subscribe@lists.xml.org >>> List archive: http://lists.xml.org/archives/xml-dev/ >>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >>> >>> >>> >>> >>> _______________________________________________________________________ >>> >>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >>> to support XML implementation and development. To minimize >>> spam in the archives, you must subscribe before posting. >>> >>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >>> subscribe: xml-dev-subscribe@lists.xml.org >>> List archive: http://lists.xml.org/archives/xml-dev/ >>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >>> >>> >> >> _______________________________________________________________________ >> >> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >> to support XML implementation and development. To minimize >> spam in the archives, you must subscribe before posting. >> >> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >> subscribe: xml-dev-subscribe@lists.xml.org >> List archive: http://lists.xml.org/archives/xml-dev/ >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >> >> >> >> > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > > > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000305951.html Fraser, I was thinking about this problem whilst stuck in a traffic jam this morning - and have devised the approach I would take. I will leave it to you to decide whether it is appropriate for the concrete scenario you face. To start with I would probably put the XML aside and work out how I would represent the same information in a relational way - what are the significant entities and what attributes do they have? IMHO I believe that any tooling based "auto-magical mapping" approach tends to make compromises such as flexibility versus simplicity. By way of example if your XML represented a purchase order you could imagine having tables such as PURCHASE_ORDER, LINE_ITEM, ADDRESS (delivery, invoice etc.). For the attributes I would suggest that you make a first guess as to what information the MI reports are likely to contain and make sure that these are represented as columns within your primary entities. To allow for extensibility you could define some additional tables (e.g. PURCHASE_ORDER_ADDITIONAL_INFO, LINE_ITEM_ADDITIONAL_INFO) that allows any additional information to be stored as key value pairs. Once you have devised the significant entities the problem becomes one of mapping the XML into the schema. This is where technology choices could be taken - do you directly map XML -> DB, XML -> Object (e.g. via Java) -> DB. Seeing as your requirements indicate that you only want to put items in the DB for reporting purposes I am not sure that an object layer adds anything. To provide flexibility I would use XSLT to map the XML directly into INSERT SQL statements that could then be run against the DB (you could take advantage of Saxon's SQL extension functions for this). You have mentioned that you may need to join some of the new information to existing records - perhaps some Saxon or java extension functions embedded in the XSLT could serve here (e.g. to do the address/postcode lookup). Alternatively you could delegate this to a stored procedure on the DB in which case the XSLT would probably require an extension function to call the stored procedure. I would also zip up the XML (to reduce storage overhead) and store it as BLOB for retrieval if other information is required in the future. Now let's consider some change scenarios. 1.] An ad-hoc/infrequent report needs to contain a new field that is not currently extracted and stored within the DB. The new field does not need to be available for retrospective reporting. Solution: modify the XSLT slightly to extract the additional information which can then be stored in you extension tables. Optionally you could create a materialised view for reporting convenience. Update or create a report that then uses the new information. 2.] The MI dashboard/BAM report (runs frequently) is missing a significant bit of information. This needs to be extracted from the XML and is also required for retrospective analysis. Solution: Create a new column on the appropriate table. Update the XSLT to map the relevant information into this new column for all new transactions. Write an upgrade tool that pulls out the original XML from the BLOB, runs an XSLT to create an UPDATE script that populates this new column. This upgrading tool could run as a background task (possible working in reverse chronological order) that would enrich the level of information available for reporting over time. Note: this may not be appropriate if your transaction volumes are high where the tooling could never keep up. In summary I think the combination of XSLT and a DB schema with deliberate extensibility factored in balances flexibility with simplicity. Michael www.xml-solutions.com On Tue, Nov 3, 2009 at 9:40 AM, Fraser Goffin <goffinf@googlemail.com>wrote: > > Do your applications that use the relational database need to update > > Thats a difficult one. As far as producing up-stream interfaces, no, > they are created just by selecting from the database. > > However, as I mentioned (lost in the detail) earlier, messages > received will have a relationship to existing records. I'm not at all > convinced that update will be possible because not all of the keys > will be available in the message received. Some form of 'fuzzy' > matching may be possible in some case, for example, if I receive a new > address then the 1st line + PostCode + the relationship of this > address to something else may be sufficient. > > It might be the case that we have to consider time based snap-shots, > i.e. the 'state' of a collection of data at a point in time. Not sure > yet, its one of those areas of difficulty that probably doesn't change > much whether I use relational of native XML stores. > > At present the primary purpose of the database is for retreival, i.e. > its NOT an operational store, its for MI, so optimiastions for read > rather than update are appropriate. > > > do they need to produce reports that present the information in multiple > ways > > Yes. > > Fraser. > > 2009/11/3 Jim Tivy <jimt@bluestream.com>: > > Do your applications that use the relational database need to update and > do > > they need to produce reports that present the information in multiple > ways > > hierarchial ways? This may suggest whether your database needs to be > > normalized (approaching 3rd Normal form)? > > > > -----Original Message----- > > From: Fraser Goffin [mailto:goffinf@googlemail.com] > > Sent: Monday, November 02, 2009 3:31 PM > > To: xml-dev@lists.xml.org > > Subject: Re: [xml-dev] Shredding XML > > > > Hi Jim, > > > > thats interesting ... which should be the 'driving' schema, XML or Db ? > > > > I guess I've been somewhat tiptoe'ing around this one. > > > > I should admit my bias if its not already apparent. I work mainly in > > the SOA integration space and since XML is the primary exchange format > > and XML schema does a reasonable job as the type system, I favour > > processing XML as .. well XML ... whilst I understand the argument > > around leveraging existing technologies and skillset .. often-times > > this is little more than protectionism and continually [de]composing > > from XML to objects then to CopyLibs and then to relational just seems > > unnecessary a lot of the time (sorry - soap box over). But of course > > the whole world isn't XML and just like most other large organisations > > the vast majority of our processing capability and data isn't and > > probably never will be ... I have no issue with that. > > > > On the one hand it is the end product that drives the design (even if > > that design has a relatively short shelf-life ... but hey, we all do > > agile right). In that case it is definately the Database schema that > > prevails from the pure delivery point of view, since this is the > > desired source for the staging area from which to produce interface > > files for upstream applications. At present there appears to be no > > possiblility of revisiting that choice. At the same time, I don't want > > to 'paint myself into a corner' or promote this as an exemplar for all > > future approaches (unless it turns out that way :-) > > > > My unease is around the brittleness of the database schema in the face > > of change, but I suppose that situation is almost inevitable since I > > can't crystal-ball what changes might be coming along next week and > > its probably folly to try. XML changes that dynamic, but not > > completely. > > > > I have been having this internal debate about, .. if I concede I'm > > going to have a relational database then should its design be derived > > from the XML schema or should the XML schema change to accomodate the > > database, indeed one of the Solution Designers on this has already > > indicated a desire to 'flatten' the XML schema (although I have to say > > I disagree that it is necessary). I have some degree of opportunity to > > change the XML schema (although messages > > are received from external sources, within reason, I can transform > > them into any 'shape' I like so long as thats a loss-less exchange). > > The database is green field so it can be any shape, but clearly some > > designs are going to lend themsleves better than others to XML mapping > > I would have thought ? > > > > Surely there are some structures in XML that don't map > > straight-forwardly. Ted Neward called this the 'last mile' (a familiar > > term to us all I'm sure), where the illusion of a high fidelity > > solution draws us in, and indeed 80%+ appears to go quite well, but > > that last few % hold a disproportiate cost and increasing complexity > > (but you don't realise that until late on at which point some are > > going to object to a rethink). I want to know where that 'last mile' > > lives so I can try and avoid it ! > > > > Fraser. > > > > 2009/11/2 Jim Tivy <jimt@bluestream.com>: > >> Fraser > >> > >> I am not entirely hearing firm commitment that you plan to establish an > > RDB > >> schema and make it the driving schema. In other words, what this would > > mean > >> is that data elements cannot be put into the RDB unless they exist in > the > >> RDB schema. For example, if some new data elements show up in some > > external > >> XML to be imported then the DBA decides whether to allow them into the > >> appropriate RDB column or not, or drop them for the time being. > >> > >> Another option (from the infinite number) would be to let the XML schema > >> generate the RDB schema and the mapping code. For your application > >> programmers using SQL on the RDB this would likely lead to gagging and > >> hacking and an "out of body experience" This is not something I would > >> recommend and if this is what you want then get a database that supports > >> XQuery and retrain your developers. > >> > >> But I think you have to choose between these two - the first being what > it > >> sounds like you want - then work backwards from that decision. > >> > >> Jim > >> > >> -----Original Message----- > >> From: Fraser Goffin [mailto:goffinf@googlemail.com] > >> Sent: Monday, November 02, 2009 12:22 PM > >> To: xml-dev@lists.xml.org > >> Subject: Re: [xml-dev] Shredding XML > >> > >> Yes Jim, that is spot on. > >> > >> Whilst there has been much discussion thus far on the technolgies and > >> techniques of getting data out of the database (and that has been > >> interesting), the programming for doing so are 'bread and butter' to > >> our mainframe Cobol and Sapiens guys, so thats not really my problem. > >> > >> Mine is the task of getting the data from a fairly complex XML content > >> model into an appropriately factored relational database. The design > >> of that database is 'green field' but (and thanks to many on this > >> thread who have posted related papers) this may not be as easy at it > >> might at first appear, what with impedence mismatches here there and > >> everywhere ;-) > >> > >> Its also the case that the XML data doesn't contain enough data > >> inherently to represent primary or foreign key values for all of the > >> relationships that are likely to arise. In some cases I MAY be > >> permitted to generate them myself (say using a UUID) as I 'walk' the > >> XML, in other cases I MAY be required to get the database to provide > >> the value(s), not sure yet. The later may increase the complexity > >> somewhat (sidenote: our DBAs don't allow stored procs (don't ask) so > >> I'm going to be doing whole bunches of INSERTs as part of the > >> tree-walk I suspect) > >> > >> I'm really interested in the gotchas and best practices. Some have > >> already been mentioned like the fact that the XML schema may define > >> optional items and unrestricted length facets and such like. Others > >> I've seen in reading talk about the mis-match of identity approaches > >> (although this was talking primarily about OO/Relational mapping but > >> the idea is similar I suspect). This could be important, since some > >> messages received may 'relate' to others already loaded and, given > >> what I said about not having all of the data in the XML to form all of > >> the keys, this might be a significant problem. > >> > >> It is my intention to look into other options (we have recently > >> acquired DB2 v9 which includes pureXML) but as is so often the case, > >> the immediate project delivery pressures won't allow it. The PM is > >> very nervous about using any new tech, perhaps justifiably, but my > >> sense of unease is more to do with the perhaps misplaced assumption > >> that 'tried and tested' tech like relational databases will always > >> provide a workable solution, imho sometimes they actually represent > >> the most significant constraint. > >> > >> So yes, back to the actual problem. How to come up with a database > >> design that provides the capability of staging the shredded XML in a > >> reasonable efficient manner and enables it to be loaded from XML > >> instances received, again efficiently (ideally without 100's of tables > >> and joins to negotiate). As far as efficiency of storage, well that > >> MAY be a concern although perhaps not a huge one so long as the Db > >> doesn't bloat up too much if normalisation is preferred over extra > >> tables. > >> > >> Please add your thoughts and suggestions and experiences as you are > >> able. Nothing is too trivial (or rude) to mention (i.e. if you want to > >> say don't do this if you want to keep your sanity, thats ok). > >> > >> regards > >> > >> Fraser. > >> > >> I'm > >> > >> > >> 2009/11/1 Jim Tivy <jimt@bluestream.com>: > >>> Interesting post, but I am not sure that "now is the time to talk of > many > >>> things". > >>> > >>> Let me try to focus: > >>> > >>> Proper software execution comes from the choice of appropriate > >>> actions/technologies to match the driving requirements. But more > >>> importantly, the greatest Wisdom, is to frame the driving requirements > >>> correctly before "going off half cocked" or doing something that is > >>> unnecessary and unwarranted. > >>> > >>> So lets start by framing the requirements again: > >>> > >>> Fraser Gofin wrote: > >>> > >>> " > >>> The basics are we receive XML messages from an external trading partner > >> and > >>> process those messages, enriching and routing to a number of internal > >>> subscriber applications. One of these applications is MI and the deal > > here > >>> is that they want the data to been put into a relational database so > that > >>> they can create a number of interfaces 'files' which are sent to still > >> more > >>> applications. > >>> " > >>> > >>> OR > >>> > >>> " > >>> I am mainly interested in the process of LOADING XML data to a database > >>> rather than extracting (at least for the purposes of this discussion). > >>> " > >>> > >>> It is possible that the "mother persistent application datamodel" is > >>> contained in the relational database in all its normalized glory. If > so, > >>> then, "processing the messages" is simply a "data import" operation. > So > >> the > >>> question is, how do I get XML X* to tables T*. It would strike me that > >> lots > >>> of people are doing this. Are there common techniques and technologies > >> for > >>> doing this import? > >>> > >>> Fraser, is that a proper framing of the question/requirements? > >>> > >>> Jim > >>> > >>> > >>> -----Original Message----- > >>> From: Petite Abeille [mailto:petite.abeille@gmail.com] > >>> Sent: Sunday, November 01, 2009 9:56 AM > >>> To: xml-dev@lists.xml.org > >>> Subject: Re: [xml-dev] Shredding XML > >>> > >>> > >>> On Oct 29, 2009, at 10:20 PM, Fraser Goffin wrote: > >>> > >>>> opinions on the subject of decomposing XML into relational databases > >>> > >>> Outside of the most trivial case, this is a major PITA of the same > >>> epic proportion as the object-relational one: > >>> > >>> > > > http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx > >>> > >>> Good luck. > >>> > >>> > >>> > >>> _______________________________________________________________________ > >>> > >>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS > >>> to support XML implementation and development. To minimize > >>> spam in the archives, you must subscribe before posting. > >>> > >>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > >>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > >>> subscribe: xml-dev-subscribe@lists.xml.org > >>> List archive: http://lists.xml.org/archives/xml-dev/ > >>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > >>> > >>> > >>> > >>> > >>> _______________________________________________________________________ > >>> > >>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS > >>> to support XML implementation and development. To minimize > >>> spam in the archives, you must subscribe before posting. > >>> > >>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > >>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > >>> subscribe: xml-dev-subscribe@lists.xml.org > >>> List archive: http://lists.xml.org/archives/xml-dev/ > >>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > >>> > >>> > >> > >> _______________________________________________________________________ > >> > >> XML-DEV is a publicly archived, unmoderated list hosted by OASIS > >> to support XML implementation and development. To minimize > >> spam in the archives, you must subscribe before posting. > >> > >> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > >> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > >> subscribe: xml-dev-subscribe@lists.xml.org > >> List archive: http://lists.xml.org/archives/xml-dev/ > >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > >> > >> > >> > >> > > > > _______________________________________________________________________ > > > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > > to support XML implementation and development. To minimize > > spam in the archives, you must subscribe before posting. > > > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > > subscribe: xml-dev-subscribe@lists.xml.org > > List archive: http://lists.xml.org/archives/xml-dev/ > > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > > > > > > > > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > >]]> http://www.altova.com/list/xml-dev/200911/msg1000305923.html > Do your applications that use the relational database need to update Thats a difficult one. As far as producing up-stream interfaces, no, they are created just by selecting from the database. However, as I mentioned (lost in the detail) earlier, messages received will have a relationship to existing records. I'm not at all convinced that update will be possible because not all of the keys will be available in the message received. Some form of 'fuzzy' matching may be possible in some case, for example, if I receive a new address then the 1st line + PostCode + the relationship of this address to something else may be sufficient. It might be the case that we have to consider time based snap-shots, i.e. the 'state' of a collection of data at a point in time. Not sure yet, its one of those areas of difficulty that probably doesn't change much whether I use relational of native XML stores. At present the primary purpose of the database is for retreival, i.e. its NOT an operational store, its for MI, so optimiastions for read rather than update are appropriate. > do they need to produce reports that present the information in multiple ways Yes. Fraser. 2009/11/3 Jim Tivy <jimt@bluestream.com>: > Do your applications that use the relational database need to update and do > they need to produce reports that present the information in multiple ways > hierarchial ways?  This may suggest whether your database needs to be > normalized (approaching 3rd Normal form)? > > -----Original Message----- > From: Fraser Goffin [mailto:goffinf@googlemail.com] > Sent: Monday, November 02, 2009 3:31 PM > To: xml-dev@lists.xml.org > Subject: Re: [xml-dev] Shredding XML > > Hi Jim, > > thats interesting ... which should be the 'driving' schema, XML or Db ? > > I guess I've been somewhat tiptoe'ing around this one. > > I should admit my bias if its not already apparent. I work mainly in > the SOA integration space and since XML is the primary exchange format > and XML schema does a reasonable job as the type system, I favour > processing XML as .. well XML ... whilst I understand the argument > around leveraging existing technologies and skillset .. often-times > this is little more than protectionism and continually [de]composing > from XML to objects then to CopyLibs and then to relational just seems > unnecessary a lot of the time (sorry - soap box over).  But of course > the whole world isn't XML and just like most other large organisations > the vast majority of our processing capability and data isn't and > probably never will be ... I have no issue with that. > > On the one hand it is the end product that drives the design (even if > that design has a relatively short shelf-life ... but hey, we all do > agile right). In that case it is definately the Database schema that > prevails from the pure delivery point of view, since this is the > desired source for the staging area from which to produce interface > files for upstream applications. At present there appears to be no > possiblility of revisiting that choice. At the same time, I don't want > to 'paint myself into a corner' or promote this as an exemplar for all > future approaches (unless it turns out that way :-) > > My unease is around the brittleness of the database schema in the face > of change, but I suppose that situation is almost inevitable since I > can't crystal-ball what changes might be coming along next week and > its probably folly to try. XML changes that dynamic, but not > completely. > > I have been having this internal debate about, .. if I concede I'm > going to have a relational database then should its design be derived > from the XML schema or should the XML schema change to accomodate the > database, indeed one of the Solution Designers on this has already > indicated a desire to 'flatten' the XML schema (although I have to say > I disagree that it is necessary). I have some degree of opportunity to > change the XML schema (although messages > are received from external sources, within reason, I can transform > them into any 'shape' I like so long as thats a loss-less exchange). > The database is green field so it can be any shape, but clearly some > designs are going to lend themsleves better than others to XML mapping > I would have thought ? > > Surely there are some structures in XML that don't map > straight-forwardly. Ted Neward called this the 'last mile' (a familiar > term to us all I'm sure), where the illusion of a high fidelity > solution draws us in, and indeed 80%+ appears to go quite well, but > that last few % hold a disproportiate cost and increasing complexity > (but you don't realise that until late on at which point some are > going to object to a rethink). I want to know where that 'last mile' > lives so I can try and avoid it ! > > Fraser. > > 2009/11/2 Jim Tivy <jimt@bluestream.com>: >> Fraser >> >> I am not entirely hearing firm commitment that you plan to establish an > RDB >> schema and make it the driving schema.  In other words, what this would > mean >> is that data elements cannot be put into the RDB unless they exist in the >> RDB schema.  For example, if some new data elements show up in some > external >> XML to be imported then the DBA decides whether to allow them into the >> appropriate RDB column or not, or drop them for the time being. >> >> Another option (from the infinite number) would be to let the XML schema >> generate the RDB schema and the mapping code.  For your application >> programmers using SQL on the RDB this would likely lead to gagging and >> hacking and an "out of body experience"  This is not something I would >> recommend and if this is what you want then get a database that supports >> XQuery and retrain your developers. >> >> But I think you have to choose between these two - the first being what it >> sounds like you want - then work backwards from that decision. >> >> Jim >> >> -----Original Message----- >> From: Fraser Goffin [mailto:goffinf@googlemail.com] >> Sent: Monday, November 02, 2009 12:22 PM >> To: xml-dev@lists.xml.org >> Subject: Re: [xml-dev] Shredding XML >> >> Yes Jim, that is spot on. >> >> Whilst there has been much discussion thus far on the technolgies and >> techniques of getting data out of the database (and that has been >> interesting), the programming for doing so are 'bread and butter' to >> our mainframe Cobol and Sapiens guys, so thats not really my problem. >> >> Mine is the task of getting the data from a fairly complex XML content >> model into an appropriately factored relational database. The design >> of that database is 'green field' but (and thanks to many on this >> thread who have posted related papers) this may not be as easy at it >> might at first appear, what with impedence mismatches here there and >> everywhere ;-) >> >> Its also the case that the XML data doesn't contain enough data >> inherently to represent primary or foreign key values for all of the >> relationships that are likely to arise. In some cases I MAY be >> permitted to generate them myself (say using a UUID) as I 'walk' the >> XML, in other cases I MAY be required to get the database to provide >> the value(s), not sure yet. The later may increase the complexity >> somewhat (sidenote: our DBAs don't allow stored procs (don't ask)  so >> I'm going to be doing whole bunches of INSERTs as part of the >> tree-walk I suspect) >> >> I'm really interested in the gotchas and best practices. Some have >> already been mentioned like the fact that the XML schema may define >> optional items and unrestricted length facets and such like. Others >> I've seen in reading talk about the mis-match of identity approaches >> (although this was talking primarily about OO/Relational mapping but >> the idea is similar I suspect). This could be important, since some >> messages received may 'relate' to others already loaded and, given >> what I said about not having all of the data in the XML to form all of >> the keys, this might be a significant problem. >> >> It is my intention to look into other options (we have recently >> acquired DB2 v9 which includes pureXML) but as is so often the case, >> the immediate project delivery pressures won't allow it. The PM is >> very nervous about using any new tech, perhaps justifiably, but my >> sense of unease is more to do with the perhaps misplaced assumption >> that 'tried and tested' tech like relational databases will always >> provide a workable solution, imho sometimes they actually represent >> the most significant constraint. >> >> So yes, back to the actual problem. How to come up with a database >> design that provides the capability of staging the shredded XML in a >> reasonable efficient manner and enables it to be loaded from XML >> instances received, again efficiently (ideally without 100's of tables >> and joins to negotiate). As far as efficiency of storage, well that >> MAY be a concern although perhaps not a huge one so long as the Db >> doesn't bloat up too much if normalisation is preferred over extra >> tables. >> >> Please add your thoughts and suggestions and experiences as you are >> able. Nothing is too trivial (or rude) to mention (i.e. if you want to >> say don't do this if you want to keep your sanity, thats ok). >> >> regards >> >> Fraser. >> >> I'm >> >> >> 2009/11/1 Jim Tivy <jimt@bluestream.com>: >>> Interesting post, but I am not sure that "now is the time to talk of many >>> things". >>> >>> Let me try to focus: >>> >>> Proper software execution comes from the choice of appropriate >>> actions/technologies to match the driving requirements.  But more >>> importantly, the greatest Wisdom, is to frame the driving requirements >>> correctly before "going off half cocked" or doing something that is >>> unnecessary and unwarranted. >>> >>> So lets start by framing the requirements again: >>> >>> Fraser Gofin wrote: >>> >>> " >>> The basics are we receive XML messages from an external trading partner >> and >>> process those messages, enriching and routing to a number of internal >>> subscriber applications. One of these applications is MI and the deal > here >>> is that they want the data to been put into a relational database so that >>> they can create a number of interfaces 'files' which are sent to still >> more >>> applications. >>> " >>> >>> OR >>> >>> " >>> I am mainly interested in the process of LOADING XML data to a database >>> rather than extracting (at least for the purposes of this discussion). >>> " >>> >>> It is possible that the "mother persistent application datamodel" is >>> contained in the relational database in all its normalized glory.  If so, >>> then, "processing the messages" is simply a "data import" operation.  So >> the >>> question is, how do I get XML X* to tables T*.  It would strike me that >> lots >>> of people are doing this.  Are there common techniques and technologies >> for >>> doing this import? >>> >>> Fraser, is that a proper framing of the question/requirements? >>> >>> Jim >>> >>> >>> -----Original Message----- >>> From: Petite Abeille [mailto:petite.abeille@gmail.com] >>> Sent: Sunday, November 01, 2009 9:56 AM >>> To: xml-dev@lists.xml.org >>> Subject: Re: [xml-dev] Shredding XML >>> >>> >>> On Oct 29, 2009, at 10:20 PM, Fraser Goffin wrote: >>> >>>> opinions on the subject of decomposing XML into relational databases >>> >>> Outside of the most trivial case, this is a major PITA of the same >>> epic proportion as the object-relational one: >>> >>> > http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx >>> >>> Good luck. >>> >>> >>> >>> _______________________________________________________________________ >>> >>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >>> to support XML implementation and development. To minimize >>> spam in the archives, you must subscribe before posting. >>> >>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >>> subscribe: xml-dev-subscribe@lists.xml.org >>> List archive: http://lists.xml.org/archives/xml-dev/ >>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >>> >>> >>> >>> >>> _______________________________________________________________________ >>> >>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >>> to support XML implementation and development. To minimize >>> spam in the archives, you must subscribe before posting. >>> >>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >>> subscribe: xml-dev-subscribe@lists.xml.org >>> List archive: http://lists.xml.org/archives/xml-dev/ >>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >>> >>> >> >> _______________________________________________________________________ >> >> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >> to support XML implementation and development. To minimize >> spam in the archives, you must subscribe before posting. >> >> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >> subscribe: xml-dev-subscribe@lists.xml.org >> List archive: http://lists.xml.org/archives/xml-dev/ >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >> >> >> >> > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > > > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000305909.html Possibly a generic schema would work... by that I mean design where the tables are "vertical" instead of "horizontal". In a vertical table approach, you have a parent column, child column, type column, and a value column. For xml shredding, add the actual element names for the child. The parent/child columns are generated keys that store the parent/child elements. Plus you'd need a table to store the attribute values: child key, attrib name, attrib type (if needed), attrib value. The value column is always a string, which must be converted to the associated type. It will take a bit of logic to do the shredding, but once written, it won't need any modification for new element nodes or new attributes. Use recursion to recover the xml hierarchical structure and element values. Join to the attribute table to pick up the attribute value (you'll need to combine the two with logic - you can't do this with a single sql statement). [Note: Oracle recursion maintains parent/child row relationships - not sure that DB2 does this; I know Teradata cannot. If DB2 does not maintain parent/child row relationships, then you'll need to write recursive logic to do this instead of a simple SQL statement.] In the end, each row in the parent/child table represents an element node (the child). And each row in the attrib table represents one attrib and value for the corresponding child element. Finally, you'll need a fake node to store the root. Hope this makes sense; sort of designed this on the fly while writing. Cheers.]]> http://www.altova.com/list/xml-dev/200911/msg1000305885.html Do your applications that use the relational database need to update and do they need to produce reports that present the information in multiple ways hierarchial ways? This may suggest whether your database needs to be normalized (approaching 3rd Normal form)? -----Original Message----- From: Fraser Goffin [mailto:goffinf@googlemail.com] Sent: Monday, November 02, 2009 3:31 PM To: xml-dev@lists.xml.org Subject: Re: [xml-dev] Shredding XML Hi Jim, thats interesting ... which should be the 'driving' schema, XML or Db ? I guess I've been somewhat tiptoe'ing around this one. I should admit my bias if its not already apparent. I work mainly in the SOA integration space and since XML is the primary exchange format and XML schema does a reasonable job as the type system, I favour processing XML as .. well XML ... whilst I understand the argument around leveraging existing technologies and skillset .. often-times this is little more than protectionism and continually [de]composing from XML to objects then to CopyLibs and then to relational just seems unnecessary a lot of the time (sorry - soap box over). But of course the whole world isn't XML and just like most other large organisations the vast majority of our processing capability and data isn't and probably never will be ... I have no issue with that. On the one hand it is the end product that drives the design (even if that design has a relatively short shelf-life ... but hey, we all do agile right). In that case it is definately the Database schema that prevails from the pure delivery point of view, since this is the desired source for the staging area from which to produce interface files for upstream applications. At present there appears to be no possiblility of revisiting that choice. At the same time, I don't want to 'paint myself into a corner' or promote this as an exemplar for all future approaches (unless it turns out that way :-) My unease is around the brittleness of the database schema in the face of change, but I suppose that situation is almost inevitable since I can't crystal-ball what changes might be coming along next week and its probably folly to try. XML changes that dynamic, but not completely. I have been having this internal debate about, .. if I concede I'm going to have a relational database then should its design be derived from the XML schema or should the XML schema change to accomodate the database, indeed one of the Solution Designers on this has already indicated a desire to 'flatten' the XML schema (although I have to say I disagree that it is necessary). I have some degree of opportunity to change the XML schema (although messages are received from external sources, within reason, I can transform them into any 'shape' I like so long as thats a loss-less exchange). The database is green field so it can be any shape, but clearly some designs are going to lend themsleves better than others to XML mapping I would have thought ? Surely there are some structures in XML that don't map straight-forwardly. Ted Neward called this the 'last mile' (a familiar term to us all I'm sure), where the illusion of a high fidelity solution draws us in, and indeed 80%+ appears to go quite well, but that last few % hold a disproportiate cost and increasing complexity (but you don't realise that until late on at which point some are going to object to a rethink). I want to know where that 'last mile' lives so I can try and avoid it ! Fraser. 2009/11/2 Jim Tivy <jimt@bluestream.com>: > Fraser > > I am not entirely hearing firm commitment that you plan to establish an RDB > schema and make it the driving schema.  In other words, what this would mean > is that data elements cannot be put into the RDB unless they exist in the > RDB schema.  For example, if some new data elements show up in some external > XML to be imported then the DBA decides whether to allow them into the > appropriate RDB column or not, or drop them for the time being. > > Another option (from the infinite number) would be to let the XML schema > generate the RDB schema and the mapping code.  For your application > programmers using SQL on the RDB this would likely lead to gagging and > hacking and an "out of body experience"  This is not something I would > recommend and if this is what you want then get a database that supports > XQuery and retrain your developers. > > But I think you have to choose between these two - the first being what it > sounds like you want - then work backwards from that decision. > > Jim > > -----Original Message----- > From: Fraser Goffin [mailto:goffinf@googlemail.com] > Sent: Monday, November 02, 2009 12:22 PM > To: xml-dev@lists.xml.org > Subject: Re: [xml-dev] Shredding XML > > Yes Jim, that is spot on. > > Whilst there has been much discussion thus far on the technolgies and > techniques of getting data out of the database (and that has been > interesting), the programming for doing so are 'bread and butter' to > our mainframe Cobol and Sapiens guys, so thats not really my problem. > > Mine is the task of getting the data from a fairly complex XML content > model into an appropriately factored relational database. The design > of that database is 'green field' but (and thanks to many on this > thread who have posted related papers) this may not be as easy at it > might at first appear, what with impedence mismatches here there and > everywhere ;-) > > Its also the case that the XML data doesn't contain enough data > inherently to represent primary or foreign key values for all of the > relationships that are likely to arise. In some cases I MAY be > permitted to generate them myself (say using a UUID) as I 'walk' the > XML, in other cases I MAY be required to get the database to provide > the value(s), not sure yet. The later may increase the complexity > somewhat (sidenote: our DBAs don't allow stored procs (don't ask)  so > I'm going to be doing whole bunches of INSERTs as part of the > tree-walk I suspect) > > I'm really interested in the gotchas and best practices. Some have > already been mentioned like the fact that the XML schema may define > optional items and unrestricted length facets and such like. Others > I've seen in reading talk about the mis-match of identity approaches > (although this was talking primarily about OO/Relational mapping but > the idea is similar I suspect). This could be important, since some > messages received may 'relate' to others already loaded and, given > what I said about not having all of the data in the XML to form all of > the keys, this might be a significant problem. > > It is my intention to look into other options (we have recently > acquired DB2 v9 which includes pureXML) but as is so often the case, > the immediate project delivery pressures won't allow it. The PM is > very nervous about using any new tech, perhaps justifiably, but my > sense of unease is more to do with the perhaps misplaced assumption > that 'tried and tested' tech like relational databases will always > provide a workable solution, imho sometimes they actually represent > the most significant constraint. > > So yes, back to the actual problem. How to come up with a database > design that provides the capability of staging the shredded XML in a > reasonable efficient manner and enables it to be loaded from XML > instances received, again efficiently (ideally without 100's of tables > and joins to negotiate). As far as efficiency of storage, well that > MAY be a concern although perhaps not a huge one so long as the Db > doesn't bloat up too much if normalisation is preferred over extra > tables. > > Please add your thoughts and suggestions and experiences as you are > able. Nothing is too trivial (or rude) to mention (i.e. if you want to > say don't do this if you want to keep your sanity, thats ok). > > regards > > Fraser. > > I'm > > > 2009/11/1 Jim Tivy <jimt@bluestream.com>: >> Interesting post, but I am not sure that "now is the time to talk of many >> things". >> >> Let me try to focus: >> >> Proper software execution comes from the choice of appropriate >> actions/technologies to match the driving requirements.  But more >> importantly, the greatest Wisdom, is to frame the driving requirements >> correctly before "going off half cocked" or doing something that is >> unnecessary and unwarranted. >> >> So lets start by framing the requirements again: >> >> Fraser Gofin wrote: >> >> " >> The basics are we receive XML messages from an external trading partner > and >> process those messages, enriching and routing to a number of internal >> subscriber applications. One of these applications is MI and the deal here >> is that they want the data to been put into a relational database so that >> they can create a number of interfaces 'files' which are sent to still > more >> applications. >> " >> >> OR >> >> " >> I am mainly interested in the process of LOADING XML data to a database >> rather than extracting (at least for the purposes of this discussion). >> " >> >> It is possible that the "mother persistent application datamodel" is >> contained in the relational database in all its normalized glory.  If so, >> then, "processing the messages" is simply a "data import" operation.  So > the >> question is, how do I get XML X* to tables T*.  It would strike me that > lots >> of people are doing this.  Are there common techniques and technologies > for >> doing this import? >> >> Fraser, is that a proper framing of the question/requirements? >> >> Jim >> >> >> -----Original Message----- >> From: Petite Abeille [mailto:petite.abeille@gmail.com] >> Sent: Sunday, November 01, 2009 9:56 AM >> To: xml-dev@lists.xml.org >> Subject: Re: [xml-dev] Shredding XML >> >> >> On Oct 29, 2009, at 10:20 PM, Fraser Goffin wrote: >> >>> opinions on the subject of decomposing XML into relational databases >> >> Outside of the most trivial case, this is a major PITA of the same >> epic proportion as the object-relational one: >> >> http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx >> >> Good luck. >> >> >> >> _______________________________________________________________________ >> >> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >> to support XML implementation and development. To minimize >> spam in the archives, you must subscribe before posting. >> >> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >> subscribe: xml-dev-subscribe@lists.xml.org >> List archive: http://lists.xml.org/archives/xml-dev/ >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >> >> >> >> >> _______________________________________________________________________ >> >> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >> to support XML implementation and development. To minimize >> spam in the archives, you must subscribe before posting. >> >> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >> subscribe: xml-dev-subscribe@lists.xml.org >> List archive: http://lists.xml.org/archives/xml-dev/ >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >> >> > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > > > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000305882.html Hi Jim, thats interesting ... which should be the 'driving' schema, XML or Db ? I guess I've been somewhat tiptoe'ing around this one. I should admit my bias if its not already apparent. I work mainly in the SOA integration space and since XML is the primary exchange format and XML schema does a reasonable job as the type system, I favour processing XML as .. well XML ... whilst I understand the argument around leveraging existing technologies and skillset .. often-times this is little more than protectionism and continually [de]composing from XML to objects then to CopyLibs and then to relational just seems unnecessary a lot of the time (sorry - soap box over). But of course the whole world isn't XML and just like most other large organisations the vast majority of our processing capability and data isn't and probably never will be ... I have no issue with that. On the one hand it is the end product that drives the design (even if that design has a relatively short shelf-life ... but hey, we all do agile right). In that case it is definately the Database schema that prevails from the pure delivery point of view, since this is the desired source for the staging area from which to produce interface files for upstream applications. At present there appears to be no possiblility of revisiting that choice. At the same time, I don't want to 'paint myself into a corner' or promote this as an exemplar for all future approaches (unless it turns out that way :-) My unease is around the brittleness of the database schema in the face of change, but I suppose that situation is almost inevitable since I can't crystal-ball what changes might be coming along next week and its probably folly to try. XML changes that dynamic, but not completely. I have been having this internal debate about, .. if I concede I'm going to have a relational database then should its design be derived from the XML schema or should the XML schema change to accomodate the database, indeed one of the Solution Designers on this has already indicated a desire to 'flatten' the XML schema (although I have to say I disagree that it is necessary). I have some degree of opportunity to change the XML schema (although messages are received from external sources, within reason, I can transform them into any 'shape' I like so long as thats a loss-less exchange). The database is green field so it can be any shape, but clearly some designs are going to lend themsleves better than others to XML mapping I would have thought ? Surely there are some structures in XML that don't map straight-forwardly. Ted Neward called this the 'last mile' (a familiar term to us all I'm sure), where the illusion of a high fidelity solution draws us in, and indeed 80%+ appears to go quite well, but that last few % hold a disproportiate cost and increasing complexity (but you don't realise that until late on at which point some are going to object to a rethink). I want to know where that 'last mile' lives so I can try and avoid it ! Fraser. 2009/11/2 Jim Tivy <jimt@bluestream.com>: > Fraser > > I am not entirely hearing firm commitment that you plan to establish an RDB > schema and make it the driving schema.  In other words, what this would mean > is that data elements cannot be put into the RDB unless they exist in the > RDB schema.  For example, if some new data elements show up in some external > XML to be imported then the DBA decides whether to allow them into the > appropriate RDB column or not, or drop them for the time being. > > Another option (from the infinite number) would be to let the XML schema > generate the RDB schema and the mapping code.  For your application > programmers using SQL on the RDB this would likely lead to gagging and > hacking and an "out of body experience"  This is not something I would > recommend and if this is what you want then get a database that supports > XQuery and retrain your developers. > > But I think you have to choose between these two - the first being what it > sounds like you want - then work backwards from that decision. > > Jim > > -----Original Message----- > From: Fraser Goffin [mailto:goffinf@googlemail.com] > Sent: Monday, November 02, 2009 12:22 PM > To: xml-dev@lists.xml.org > Subject: Re: [xml-dev] Shredding XML > > Yes Jim, that is spot on. > > Whilst there has been much discussion thus far on the technolgies and > techniques of getting data out of the database (and that has been > interesting), the programming for doing so are 'bread and butter' to > our mainframe Cobol and Sapiens guys, so thats not really my problem. > > Mine is the task of getting the data from a fairly complex XML content > model into an appropriately factored relational database. The design > of that database is 'green field' but (and thanks to many on this > thread who have posted related papers) this may not be as easy at it > might at first appear, what with impedence mismatches here there and > everywhere ;-) > > Its also the case that the XML data doesn't contain enough data > inherently to represent primary or foreign key values for all of the > relationships that are likely to arise. In some cases I MAY be > permitted to generate them myself (say using a UUID) as I 'walk' the > XML, in other cases I MAY be required to get the database to provide > the value(s), not sure yet. The later may increase the complexity > somewhat (sidenote: our DBAs don't allow stored procs (don't ask)  so > I'm going to be doing whole bunches of INSERTs as part of the > tree-walk I suspect) > > I'm really interested in the gotchas and best practices. Some have > already been mentioned like the fact that the XML schema may define > optional items and unrestricted length facets and such like. Others > I've seen in reading talk about the mis-match of identity approaches > (although this was talking primarily about OO/Relational mapping but > the idea is similar I suspect). This could be important, since some > messages received may 'relate' to others already loaded and, given > what I said about not having all of the data in the XML to form all of > the keys, this might be a significant problem. > > It is my intention to look into other options (we have recently > acquired DB2 v9 which includes pureXML) but as is so often the case, > the immediate project delivery pressures won't allow it. The PM is > very nervous about using any new tech, perhaps justifiably, but my > sense of unease is more to do with the perhaps misplaced assumption > that 'tried and tested' tech like relational databases will always > provide a workable solution, imho sometimes they actually represent > the most significant constraint. > > So yes, back to the actual problem. How to come up with a database > design that provides the capability of staging the shredded XML in a > reasonable efficient manner and enables it to be loaded from XML > instances received, again efficiently (ideally without 100's of tables > and joins to negotiate). As far as efficiency of storage, well that > MAY be a concern although perhaps not a huge one so long as the Db > doesn't bloat up too much if normalisation is preferred over extra > tables. > > Please add your thoughts and suggestions and experiences as you are > able. Nothing is too trivial (or rude) to mention (i.e. if you want to > say don't do this if you want to keep your sanity, thats ok). > > regards > > Fraser. > > I'm > > > 2009/11/1 Jim Tivy <jimt@bluestream.com>: >> Interesting post, but I am not sure that "now is the time to talk of many >> things". >> >> Let me try to focus: >> >> Proper software execution comes from the choice of appropriate >> actions/technologies to match the driving requirements.  But more >> importantly, the greatest Wisdom, is to frame the driving requirements >> correctly before "going off half cocked" or doing something that is >> unnecessary and unwarranted. >> >> So lets start by framing the requirements again: >> >> Fraser Gofin wrote: >> >> " >> The basics are we receive XML messages from an external trading partner > and >> process those messages, enriching and routing to a number of internal >> subscriber applications. One of these applications is MI and the deal here >> is that they want the data to been put into a relational database so that >> they can create a number of interfaces 'files' which are sent to still > more >> applications. >> " >> >> OR >> >> " >> I am mainly interested in the process of LOADING XML data to a database >> rather than extracting (at least for the purposes of this discussion). >> " >> >> It is possible that the "mother persistent application datamodel" is >> contained in the relational database in all its normalized glory.  If so, >> then, "processing the messages" is simply a "data import" operation.  So > the >> question is, how do I get XML X* to tables T*.  It would strike me that > lots >> of people are doing this.  Are there common techniques and technologies > for >> doing this import? >> >> Fraser, is that a proper framing of the question/requirements? >> >> Jim >> >> >> -----Original Message----- >> From: Petite Abeille [mailto:petite.abeille@gmail.com] >> Sent: Sunday, November 01, 2009 9:56 AM >> To: xml-dev@lists.xml.org >> Subject: Re: [xml-dev] Shredding XML >> >> >> On Oct 29, 2009, at 10:20 PM, Fraser Goffin wrote: >> >>> opinions on the subject of decomposing XML into relational databases >> >> Outside of the most trivial case, this is a major PITA of the same >> epic proportion as the object-relational one: >> >> http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx >> >> Good luck. >> >> >> >> _______________________________________________________________________ >> >> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >> to support XML implementation and development. To minimize >> spam in the archives, you must subscribe before posting. >> >> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >> subscribe: xml-dev-subscribe@lists.xml.org >> List archive: http://lists.xml.org/archives/xml-dev/ >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >> >> >> >> >> _______________________________________________________________________ >> >> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >> to support XML implementation and development. To minimize >> spam in the archives, you must subscribe before posting. >> >> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >> subscribe: xml-dev-subscribe@lists.xml.org >> List archive: http://lists.xml.org/archives/xml-dev/ >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >> >> > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > > > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000305879.html Back in August, the XML Query Working Group announced the availability of version 1.0.0 of the XQuery Update Facility Test Suite [1]. This test suite reflects the XQuery Update Facility 1.0 Candidate Recommendation [2] that was published on June 9. We are pleased to have received results from Saxonica. We'd like to encourage other implementators to submit their results to us, so that we can advance XQuery Update Facility to W3C Recommendation. -- Andrew [1] XQuery Update Facility Test Suite http://dev.w3.org/2007/xquery-update-10-test-suite/ [2] XQuery Update Facility 1.0 http://www.w3.org/TR/2009/CR-xquery-update-10-20090609/ -------------------- Andrew Eisenberg IBM 4 Technology Park Drive Westford, MA 01886 andrew.eisenberg@us.ibm.com]]> http://www.altova.com/list/xml-dev/200911/msg1000305878.html On Mon, Nov 02, 2009 at 01:57:32PM -0800, Jim Tivy wrote: > I am not entirely hearing firm commitment that you plan to establish an RDB > schema and make it the driving schema. In other words, what this would mean > is that data elements cannot be put into the RDB unless they exist in the > RDB schema. [...[ > Another option (from the infinite number) would be to let the XML schema > generate the RDB schema and the mapping code. Another is to have a column called "elementname"... It's even worse in practice, though -- Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/ http://www.holoweb.net/~liam/ * http://www.fromoldbooks.org/ _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000305874.html Fraser I am not entirely hearing firm commitment that you plan to establish an RDB schema and make it the driving schema. In other words, what this would mean is that data elements cannot be put into the RDB unless they exist in the RDB schema. For example, if some new data elements show up in some external XML to be imported then the DBA decides whether to allow them into the appropriate RDB column or not, or drop them for the time being. Another option (from the infinite number) would be to let the XML schema generate the RDB schema and the mapping code. For your application programmers using SQL on the RDB this would likely lead to gagging and hacking and an "out of body experience" This is not something I would recommend and if this is what you want then get a database that supports XQuery and retrain your developers. But I think you have to choose between these two - the first being what it sounds like you want - then work backwards from that decision. Jim -----Original Message----- From: Fraser Goffin [mailto:goffinf@googlemail.com] Sent: Monday, November 02, 2009 12:22 PM To: xml-dev@lists.xml.org Subject: Re: [xml-dev] Shredding XML Yes Jim, that is spot on. Whilst there has been much discussion thus far on the technolgies and techniques of getting data out of the database (and that has been interesting), the programming for doing so are 'bread and butter' to our mainframe Cobol and Sapiens guys, so thats not really my problem. Mine is the task of getting the data from a fairly complex XML content model into an appropriately factored relational database. The design of that database is 'green field' but (and thanks to many on this thread who have posted related papers) this may not be as easy at it might at first appear, what with impedence mismatches here there and everywhere ;-) Its also the case that the XML data doesn't contain enough data inherently to represent primary or foreign key values for all of the relationships that are likely to arise. In some cases I MAY be permitted to generate them myself (say using a UUID) as I 'walk' the XML, in other cases I MAY be required to get the database to provide the value(s), not sure yet. The later may increase the complexity somewhat (sidenote: our DBAs don't allow stored procs (don't ask) so I'm going to be doing whole bunches of INSERTs as part of the tree-walk I suspect) I'm really interested in the gotchas and best practices. Some have already been mentioned like the fact that the XML schema may define optional items and unrestricted length facets and such like. Others I've seen in reading talk about the mis-match of identity approaches (although this was talking primarily about OO/Relational mapping but the idea is similar I suspect). This could be important, since some messages received may 'relate' to others already loaded and, given what I said about not having all of the data in the XML to form all of the keys, this might be a significant problem. It is my intention to look into other options (we have recently acquired DB2 v9 which includes pureXML) but as is so often the case, the immediate project delivery pressures won't allow it. The PM is very nervous about using any new tech, perhaps justifiably, but my sense of unease is more to do with the perhaps misplaced assumption that 'tried and tested' tech like relational databases will always provide a workable solution, imho sometimes they actually represent the most significant constraint. So yes, back to the actual problem. How to come up with a database design that provides the capability of staging the shredded XML in a reasonable efficient manner and enables it to be loaded from XML instances received, again efficiently (ideally without 100's of tables and joins to negotiate). As far as efficiency of storage, well that MAY be a concern although perhaps not a huge one so long as the Db doesn't bloat up too much if normalisation is preferred over extra tables. Please add your thoughts and suggestions and experiences as you are able. Nothing is too trivial (or rude) to mention (i.e. if you want to say don't do this if you want to keep your sanity, thats ok). regards Fraser. I'm 2009/11/1 Jim Tivy <jimt@bluestream.com>: > Interesting post, but I am not sure that "now is the time to talk of many > things". > > Let me try to focus: > > Proper software execution comes from the choice of appropriate > actions/technologies to match the driving requirements.  But more > importantly, the greatest Wisdom, is to frame the driving requirements > correctly before "going off half cocked" or doing something that is > unnecessary and unwarranted. > > So lets start by framing the requirements again: > > Fraser Gofin wrote: > > " > The basics are we receive XML messages from an external trading partner and > process those messages, enriching and routing to a number of internal > subscriber applications. One of these applications is MI and the deal here > is that they want the data to been put into a relational database so that > they can create a number of interfaces 'files' which are sent to still more > applications. > " > > OR > > " > I am mainly interested in the process of LOADING XML data to a database > rather than extracting (at least for the purposes of this discussion). > " > > It is possible that the "mother persistent application datamodel" is > contained in the relational database in all its normalized glory.  If so, > then, "processing the messages" is simply a "data import" operation.  So the > question is, how do I get XML X* to tables T*.  It would strike me that lots > of people are doing this.  Are there common techniques and technologies for > doing this import? > > Fraser, is that a proper framing of the question/requirements? > > Jim > > > -----Original Message----- > From: Petite Abeille [mailto:petite.abeille@gmail.com] > Sent: Sunday, November 01, 2009 9:56 AM > To: xml-dev@lists.xml.org > Subject: Re: [xml-dev] Shredding XML > > > On Oct 29, 2009, at 10:20 PM, Fraser Goffin wrote: > >> opinions on the subject of decomposing XML into relational databases > > Outside of the most trivial case, this is a major PITA of the same > epic proportion as the object-relational one: > > http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx > > Good luck. > > > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > > > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000305870.html > The PM is very nervous about using any new > tech, perhaps justifiably, but my sense of unease ... That's the essence of the problem: the PM is a Luddite. Now, there are plenty of projects that fail because they're over-ambitious in using new technology. But there are also lots of projects that cost 10 times what they should through failing to use it. I've certainly been in environments where a PM's career was advanced through delivering a successful project because no-one in higher management ever knew that it could have been done for a tenth the cost. Indeed, a $1m project looked better on his CV than a $100K project. Perhaps that's the environment you're working in. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000305862.html Yes Jim, that is spot on. Whilst there has been much discussion thus far on the technolgies and techniques of getting data out of the database (and that has been interesting), the programming for doing so are 'bread and butter' to our mainframe Cobol and Sapiens guys, so thats not really my problem. Mine is the task of getting the data from a fairly complex XML content model into an appropriately factored relational database. The design of that database is 'green field' but (and thanks to many on this thread who have posted related papers) this may not be as easy at it might at first appear, what with impedence mismatches here there and everywhere ;-) Its also the case that the XML data doesn't contain enough data inherently to represent primary or foreign key values for all of the relationships that are likely to arise. In some cases I MAY be permitted to generate them myself (say using a UUID) as I 'walk' the XML, in other cases I MAY be required to get the database to provide the value(s), not sure yet. The later may increase the complexity somewhat (sidenote: our DBAs don't allow stored procs (don't ask) so I'm going to be doing whole bunches of INSERTs as part of the tree-walk I suspect) I'm really interested in the gotchas and best practices. Some have already been mentioned like the fact that the XML schema may define optional items and unrestricted length facets and such like. Others I've seen in reading talk about the mis-match of identity approaches (although this was talking primarily about OO/Relational mapping but the idea is similar I suspect). This could be important, since some messages received may 'relate' to others already loaded and, given what I said about not having all of the data in the XML to form all of the keys, this might be a significant problem. It is my intention to look into other options (we have recently acquired DB2 v9 which includes pureXML) but as is so often the case, the immediate project delivery pressures won't allow it. The PM is very nervous about using any new tech, perhaps justifiably, but my sense of unease is more to do with the perhaps misplaced assumption that 'tried and tested' tech like relational databases will always provide a workable solution, imho sometimes they actually represent the most significant constraint. So yes, back to the actual problem. How to come up with a database design that provides the capability of staging the shredded XML in a reasonable efficient manner and enables it to be loaded from XML instances received, again efficiently (ideally without 100's of tables and joins to negotiate). As far as efficiency of storage, well that MAY be a concern although perhaps not a huge one so long as the Db doesn't bloat up too much if normalisation is preferred over extra tables. Please add your thoughts and suggestions and experiences as you are able. Nothing is too trivial (or rude) to mention (i.e. if you want to say don't do this if you want to keep your sanity, thats ok). regards Fraser. I'm 2009/11/1 Jim Tivy <jimt@bluestream.com>: > Interesting post, but I am not sure that "now is the time to talk of many > things". > > Let me try to focus: > > Proper software execution comes from the choice of appropriate > actions/technologies to match the driving requirements.  But more > importantly, the greatest Wisdom, is to frame the driving requirements > correctly before "going off half cocked" or doing something that is > unnecessary and unwarranted. > > So lets start by framing the requirements again: > > Fraser Gofin wrote: > > " > The basics are we receive XML messages from an external trading partner and > process those messages, enriching and routing to a number of internal > subscriber applications. One of these applications is MI and the deal here > is that they want the data to been put into a relational database so that > they can create a number of interfaces 'files' which are sent to still more > applications. > " > > OR > > " > I am mainly interested in the process of LOADING XML data to a database > rather than extracting (at least for the purposes of this discussion). > " > > It is possible that the "mother persistent application datamodel" is > contained in the relational database in all its normalized glory.  If so, > then, "processing the messages" is simply a "data import" operation.  So the > question is, how do I get XML X* to tables T*.  It would strike me that lots > of people are doing this.  Are there common techniques and technologies for > doing this import? > > Fraser, is that a proper framing of the question/requirements? > > Jim > > > -----Original Message----- > From: Petite Abeille [mailto:petite.abeille@gmail.com] > Sent: Sunday, November 01, 2009 9:56 AM > To: xml-dev@lists.xml.org > Subject: Re: [xml-dev] Shredding XML > > > On Oct 29, 2009, at 10:20 PM, Fraser Goffin wrote: > >> opinions on the subject of decomposing XML into relational databases > > Outside of the most trivial case, this is a major PITA of the same > epic proportion as the object-relational one: > > http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx > > Good luck. > > > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > > > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000305861.html > It is possible that the "mother persistent application datamodel" is > contained in the relational database in all its normalized glory.  If so, > then, "processing the messages" is simply a "data import" operation.  So the > question is, how do I get XML X* to tables T*.  It would strike me that lots > of people are doing this.  Are there common techniques and technologies for > doing this import? SAX parse XML into Hibernate pojos, or sometimes its easier to parse into plain old pojos the mirror the XML structure more closely (to avoid too much complexity in the SAX parser) and then have another class that copies the data into the Hibernate pojos. If you need to get the XML back out again, then you'll need a custom XML writer (serialiser) to go over the pojos and create the XML (and possibly another class to copy the data in the other direction) That's quite a lot or work if the XML is large and varied, and every time the XML changes there are quite a few code changes needed, but its not too bad.. I much prefer doing this to using data binding. -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/ _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000305820.html Interesting post, but I am not sure that "now is the time to talk of many things". Let me try to focus: Proper software execution comes from the choice of appropriate actions/technologies to match the driving requirements. But more importantly, the greatest Wisdom, is to frame the driving requirements correctly before "going off half cocked" or doing something that is unnecessary and unwarranted. So lets start by framing the requirements again: Fraser Gofin wrote: " The basics are we receive XML messages from an external trading partner and process those messages, enriching and routing to a number of internal subscriber applications. One of these applications is MI and the deal here is that they want the data to been put into a relational database so that they can create a number of interfaces 'files' which are sent to still more applications. " OR " I am mainly interested in the process of LOADING XML data to a database rather than extracting (at least for the purposes of this discussion). " It is possible that the "mother persistent application datamodel" is contained in the relational database in all its normalized glory. If so, then, "processing the messages" is simply a "data import" operation. So the question is, how do I get XML X* to tables T*. It would strike me that lots of people are doing this. Are there common techniques and technologies for doing this import? Fraser, is that a proper framing of the question/requirements? Jim -----Original Message----- From: Petite Abeille [mailto:petite.abeille@gmail.com] Sent: Sunday, November 01, 2009 9:56 AM To: xml-dev@lists.xml.org Subject: Re: [xml-dev] Shredding XML On Oct 29, 2009, at 10:20 PM, Fraser Goffin wrote: > opinions on the subject of decomposing XML into relational databases Outside of the most trivial case, this is a major PITA of the same epic proportion as the object-relational one: http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx Good luck. _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000305788.html On Oct 29, 2009, at 10:20 PM, Fraser Goffin wrote: > opinions on the subject of decomposing XML into relational databases Outside of the most trivial case, this is a major PITA of the same epic proportion as the object-relational one: http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx Good luck. _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000305783.html On Sat, 2009-10-31 at 01:05 +0000, Fraser Goffin wrote: > Thanks for the great comments thus far from every one. > > Several people have mentioned using BLOB or CLOB and indeed this is > something we have done in the recent past. However, one of the key > issues is that at least some the applications that will access the > data are either not XML capable and/or the programmers using them are > not really that familiar. Whilst its possible to process XML data > natively in Cobol, most of the time this is not the approach thats > taken, and resource constraints and project deadlines often mitigate > towards existing skills, technologies and practices. > > So I'm really interested in experience of shredding moderately complex > XML content models into relational tables (for example structures that > might produce 30-50 even possibly more tables when decomposed). And > also some arguments for and against that approach (I would like to be > able to make a compelling case for moving towards treating XML as a > first class type system rather than one which just providing a format > for data exchange). > > One of the suggestions from one of our solution designers was to > 'flatten' the XML structure and represent relationships using > keys/ids, that is, make the XML more like the database. Personally I > like the contextual relationships implicit in the hierarchical content > model and am not really keen to navigate around the document using ID > values as opposed to simply walking the tree ... but maybe others > people's experience could provide some use cases where that approach > has merit ?. You definately should have a look at the XPath Accelerator Scheme originally developed from Thorsten Grust (which can even be enhanced), the Staircase Join and various tree based enhancements to rewrite XQuery queries into (very) efficient SQL queries. > I am mainly interested in the process of LOADING XML data to a > database rather than extracting (at least for the purposes of this > discussion). So another key issue (excuse the pun) is that I will be > processing the XML data and at various points contructing SQL INSERT > statements including gathering together all of the [primary] key > values that identify each entity and their [foreign] key > relationship(s). Not all the data to support those relationships is > inherent in the source XML data, so I also need to think about > generating key values either from the database or as part of the XML > processing. Of course use of stored procedures are another aspect in > terms of positioning of the business/transformation logic. You can parse XML (possibly very large XML files) with for instance SAX and generate the appropriate relational encoding. With the XPath Accelerator scheme you preserve the tree relationship, document order and so on _and_ it has an inherit knowledge of each XPath axis, so one can rewrite XQuery statements in SQL (with tree knowledge you can also avoid duplicates efficiently, skip certain nodes etc.pp and with the staircase join you have a very efficient JOIN operator). HTH, Johannes _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200911/msg1000305771.html On Fri, Oct 30, 2009 at 2:50 AM, Fraser Goffin <goffinf@googlemail.com> wrote: > IBM for example has pureXML. I haven't used these enough to know if they're just a thin > veneer of whether they have real substance and depth, so again your > experiences are welcome. I wrote a small writeup about, XML support in DB2 a while ago. Here's a link to that, please: http://gandhimukul.tripod.com/db2_9.htm. Any comments are welcome, please. I am a bit biased towards DB2 :) -- Regards, Mukul Gandhi _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000305687.html Hi, Are you in the java world? If so, check out jaxb and specifically hyperjaxb https://hyperjaxb.dev.java.net/ JAXB allows you to take an XML document and load it into POJOs. HyperJAXB connect those POJOs to the DB. So, depending on the complexity of you app, all of your shredding could happen behind the scenes. best, -Rob On Oct 30, 2009, at 6:05 PM, Fraser Goffin wrote: > Thanks for the great comments thus far from every one. > > Several people have mentioned using BLOB or CLOB and indeed this is > something we have done in the recent past. However, one of the key > issues is that at least some the applications that will access the > data are either not XML capable and/or the programmers using them are > not really that familiar. Whilst its possible to process XML data > natively in Cobol, most of the time this is not the approach thats > taken, and resource constraints and project deadlines often mitigate > towards existing skills, technologies and practices. > > So I'm really interested in experience of shredding moderately complex > XML content models into relational tables (for example structures that > might produce 30-50 even possibly more tables when decomposed). And > also some arguments for and against that approach (I would like to be > able to make a compelling case for moving towards treating XML as a > first class type system rather than one which just providing a format > for data exchange). > > One of the suggestions from one of our solution designers was to > 'flatten' the XML structure and represent relationships using > keys/ids, that is, make the XML more like the database. Personally I > like the contextual relationships implicit in the hierarchical content > model and am not really keen to navigate around the document using ID > values as opposed to simply walking the tree ... but maybe others > people's experience could provide some use cases where that approach > has merit ?. > > I am mainly interested in the process of LOADING XML data to a > database rather than extracting (at least for the purposes of this > discussion). So another key issue (excuse the pun) is that I will be > processing the XML data and at various points contructing SQL INSERT > statements including gathering together all of the [primary] key > values that identify each entity and their [foreign] key > relationship(s). Not all the data to support those relationships is > inherent in the source XML data, so I also need to think about > generating key values either from the database or as part of the XML > processing. Of course use of stored procedures are another aspect in > terms of positioning of the business/transformation logic. > > I want to also consider differences in the type systems that might be > problematic. Some people have already mentioned structured vs. > unstructured data as well as the volatility of the XML content model > (or at least the benefit of potentially less disruptive change control > of XML vs. a database schema). > > Please keep the comments coming. I have read some of the articles that > were provided many going back to 2001 (guess this is not a new subject > :-) > > Regards > > Fraser. > > > > > 2009/10/30 Jim Tivy <jimt@bluestream.com>: >> Choice - BLOB: Use a CLOB or BLOB column for the entire XML >> document. MySQL >> has a maximum of 1 or 2 GIG there. Then process in memory using >> XSLT, >> XQuery or what have you (Saxon 9). Extract index values to other >> columns as >> necessary to make selective loading faster. >> >> Choice - Package: Buy something that does this slice and dice for >> you. >> Perhaps Progress/DataDirect has something. >> >> Choice - XML column: Create a column of XML type in DB2 or Oracle >> and do an >> XQuery on that column. >> >> Choice - get MS SQL Server. I think their first approach at >> supporting XML >> was to slice and dice - may still be that way. From what I can tell >> Microsoft's approach was clumsy for alot of uses. >> >> Choice - Native XML database. >> >> You will have to decide which of these to do given your requirements. >> >> -----Original Message----- >> From: Michael Sokolov [mailto:sokolov@ifactory.com] >> Sent: Thursday, October 29, 2009 7:42 PM >> To: 'Fraser Goffin'; xml-dev@lists.xml.org >> Subject: RE: [xml-dev] Shredding XML >> >> I spent a little while evaluating DB-2 and Oracle XQuery >> implementations - >> didn't go so far as to implement a full-blown system though, I >> guess because >> nobody was holding a gun to my head. >> >> The whole automated shredding approach strikes me as totally >> unworkable for >> data with any complexity (think about David Lee's 80 table joins), >> and >> unneccessary for simple data, where you might as well map by hand. >> One >> complication is that a schema is absolutely required, and if the >> schema >> changes, you need to re-run the entire table generation process. >> When I >> checked, it was looking like it could be quite complex to retain >> data in >> such a case: there didn't seem to be the ability to generate >> incremental >> schema change operations, so probably it would be necessary to >> migrate data >> from an old set of tables to a new set (with the same names!). >> >> Then I considered the approach of storing an XML blob or two >> attached to a >> metatdata record. I could tell it would have been possible to >> implement, >> and we probably could have gotten it working with some reasonable >> computational efficiency in the end system. However the programming >> environment was looking very hostile: there are uncomfortable >> lexical issues >> that arise when embedding XQuery in SQL or vice versa, and the idea >> of >> passing values back and forth between the two different type >> systems was >> making me uneasy. I also found that the full text support (which >> for me is >> absolutely critical) in DB-2 was lacking - when I checked they were >> in the >> midst of a transition from an older, imperfect but functioning >> system to a >> newer, but less functional one; the situation with full text is >> probably >> better in Oracle; I didn't dig deep enough to find out details. >> >> It does sound as if your data may be more record-oriented than >> mine, which >> is almost always documents written in English or some natural >> language, with >> tagging to make it at least somewhat machine-friendly. So, as >> Michael Kay >> said, if it's *already* record-oriented data that has just been >> wrapped up >> in angle brackets, you might not run into these problems. >> >> -Mike >> >> >>> -----Original Message----- >>> From: Fraser Goffin [mailto:goffinf@googlemail.com] >>> Sent: Thursday, October 29, 2009 5:20 PM >>> To: xml-dev@lists.xml.org >>> Subject: [xml-dev] Shredding XML >>> >>> This list has been unusually quiet of late so I thought it >>> might be an opportune moment to ask for opinions on the >>> subject of decomposing XML into relational databases, often >>> referred to as 'shredding'. >>> >>> My particular interest is related to some work I'm currently >>> engaged in. The basics are we receive XML messages from an >>> external trading partner and process those messages, >>> enriching and routing to a number of internal subscriber >>> applications. One of these applications is MI and the deal >>> here is that they want the data to been put into a relational >>> database so that they can create a number of interfaces >>> 'files' which are sent to still more applications. >>> >>> Whilst I would like to consider a pure XML database or even >>> use some of the XML features that are increasingly prevalent >>> in mainstream DB vendor products, clearly putting data into a >>> 'staging' database is one thing, but the capabilities and >>> competances of the applications and application programmers >>> who want to retrieve it is a key factor. So, for the >>> immediate term I might be stuck (if thats fair - probably >>> not) with relational. >>> >>> So to better inform myself and maybe help the debate along >>> internally, I am interested in anyone else experience good >>> and bad, of shredding XML data, pitfalls, things to be aware >>> of, good approaches, when to really not do it. All thoughts >>> are welcome. >>> >>> I find it intersting the some of the 'big boys' are at least >>> giving the appearance of providing first-class support for >>> XML both in terms of storage options and manipulation >>> capability. IBM for example has pureXML. I haven't used these >>> enough to know if they're just a thin veneer of whether they >>> have real substance and depth, so again your experiences are >>> welcome. >>> >>> Regards >>> >>> Fraser, >>> >>> ______________________________________________________________ >>> _________ >>> >>> XML-DEV is a publicly archived, unmoderated list hosted by >>> OASIS to support XML implementation and development. To >>> minimize spam in the archives, you must subscribe before posting. >>> >>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >>> subscribe: xml-dev-subscribe@lists.xml.org List archive: >>> http://lists.xml.org/archives/xml-dev/ >>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >>> >>> >> >> >> _______________________________________________________________________ >> >> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >> to support XML implementation and development. To minimize >> spam in the archives, you must subscribe before posting. >> >> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >> subscribe: xml-dev-subscribe@lists.xml.org >> List archive: http://lists.xml.org/archives/xml-dev/ >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >> >> >> >> > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000305681.html Thanks for the great comments thus far from every one. Several people have mentioned using BLOB or CLOB and indeed this is something we have done in the recent past. However, one of the key issues is that at least some the applications that will access the data are either not XML capable and/or the programmers using them are not really that familiar. Whilst its possible to process XML data natively in Cobol, most of the time this is not the approach thats taken, and resource constraints and project deadlines often mitigate towards existing skills, technologies and practices. So I'm really interested in experience of shredding moderately complex XML content models into relational tables (for example structures that might produce 30-50 even possibly more tables when decomposed). And also some arguments for and against that approach (I would like to be able to make a compelling case for moving towards treating XML as a first class type system rather than one which just providing a format for data exchange). One of the suggestions from one of our solution designers was to 'flatten' the XML structure and represent relationships using keys/ids, that is, make the XML more like the database. Personally I like the contextual relationships implicit in the hierarchical content model and am not really keen to navigate around the document using ID values as opposed to simply walking the tree ... but maybe others people's experience could provide some use cases where that approach has merit ?. I am mainly interested in the process of LOADING XML data to a database rather than extracting (at least for the purposes of this discussion). So another key issue (excuse the pun) is that I will be processing the XML data and at various points contructing SQL INSERT statements including gathering together all of the [primary] key values that identify each entity and their [foreign] key relationship(s). Not all the data to support those relationships is inherent in the source XML data, so I also need to think about generating key values either from the database or as part of the XML processing. Of course use of stored procedures are another aspect in terms of positioning of the business/transformation logic. I want to also consider differences in the type systems that might be problematic. Some people have already mentioned structured vs. unstructured data as well as the volatility of the XML content model (or at least the benefit of potentially less disruptive change control of XML vs. a database schema). Please keep the comments coming. I have read some of the articles that were provided many going back to 2001 (guess this is not a new subject :-) Regards Fraser. 2009/10/30 Jim Tivy <jimt@bluestream.com>: > Choice - BLOB: Use a CLOB or BLOB column for the entire XML document.  MySQL > has a maximum of 1 or 2 GIG there.  Then process in memory using XSLT, > XQuery or what have you (Saxon 9).  Extract index values to other columns as > necessary to make selective loading faster. > > Choice - Package: Buy something that does this slice and dice for you. > Perhaps Progress/DataDirect has something. > > Choice - XML column: Create a column of XML type in DB2 or Oracle and do an > XQuery on that column. > > Choice - get MS SQL Server.  I think their first approach at supporting XML > was to slice and dice - may still be that way.  From what I can tell > Microsoft's approach was clumsy for alot of uses. > > Choice - Native XML database. > > You will have to decide which of these to do given your requirements. > > -----Original Message----- > From: Michael Sokolov [mailto:sokolov@ifactory.com] > Sent: Thursday, October 29, 2009 7:42 PM > To: 'Fraser Goffin'; xml-dev@lists.xml.org > Subject: RE: [xml-dev] Shredding XML > > I spent a little while evaluating DB-2 and Oracle XQuery implementations - > didn't go so far as to implement a full-blown system though, I guess because > nobody was holding a gun to my head. > > The whole automated shredding approach strikes me as totally unworkable for > data with any complexity (think about David Lee's 80 table joins), and > unneccessary for simple data, where you might as well map by hand.  One > complication is that a schema is absolutely required, and if the schema > changes, you need to re-run the entire table generation process.  When I > checked, it was looking like it could be quite complex to retain data in > such a case: there didn't seem to be the ability to generate incremental > schema change operations, so probably it would be necessary to migrate data > from an old set of tables to a new set (with the same names!). > > Then I considered the approach of storing an XML blob or two attached to a > metatdata record.  I could tell it would have been possible to implement, > and we probably could have gotten it working with some reasonable > computational efficiency in the end system.  However the programming > environment was looking very hostile: there are uncomfortable lexical issues > that arise when embedding XQuery in SQL or vice versa, and the idea of > passing values back and forth between the two different type systems was > making me uneasy.  I also found that the full text support (which for me is > absolutely critical) in DB-2 was lacking - when I checked they were in the > midst of a transition from an older, imperfect but functioning system to a > newer, but less functional one; the situation with full text is probably > better in Oracle; I didn't dig deep enough to find out details. > > It does sound as if your data may be more record-oriented than mine, which > is almost always documents written in English or some natural language, with > tagging to make it at least somewhat machine-friendly.  So, as Michael Kay > said, if it's *already* record-oriented data that has just been wrapped up > in angle brackets, you might not run into these problems. > > -Mike > > >> -----Original Message----- >> From: Fraser Goffin [mailto:goffinf@googlemail.com] >> Sent: Thursday, October 29, 2009 5:20 PM >> To: xml-dev@lists.xml.org >> Subject: [xml-dev] Shredding XML >> >> This list has been unusually quiet of late so I thought it >> might be an opportune moment to ask for opinions on the >> subject of decomposing XML into relational databases, often >> referred to as 'shredding'. >> >> My particular interest is related to some work I'm currently >> engaged in. The basics are we receive XML messages from an >> external trading partner and process those messages, >> enriching and routing to a number of internal subscriber >> applications. One of these applications is MI and the deal >> here is that they want the data to been put into a relational >> database so that they can create a number of interfaces >> 'files' which are sent to still more applications. >> >> Whilst I would like to consider a pure XML database or even >> use some of the XML features that are increasingly prevalent >> in mainstream DB vendor products, clearly putting data into a >> 'staging' database is one thing, but the capabilities and >> competances of the applications and application programmers >> who want to retrieve it is a key factor. So, for the >> immediate term I might be stuck (if thats fair - probably >> not) with relational. >> >> So to better inform myself and maybe help the debate along >> internally, I am interested in anyone else experience good >> and bad, of shredding XML data, pitfalls, things to be aware >> of, good approaches, when to really not do it. All thoughts >> are welcome. >> >> I find it intersting the some of the 'big boys' are at least >> giving the appearance of providing first-class support for >> XML both in terms of storage options and manipulation >> capability. IBM for example has pureXML. I haven't used these >> enough to know if they're just a thin veneer of whether they >> have real substance and depth, so again your experiences are welcome. >> >> Regards >> >> Fraser, >> >> ______________________________________________________________ >> _________ >> >> XML-DEV is a publicly archived, unmoderated list hosted by >> OASIS to support XML implementation and development. To >> minimize spam in the archives, you must subscribe before posting. >> >> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >> subscribe: xml-dev-subscribe@lists.xml.org List archive: >> http://lists.xml.org/archives/xml-dev/ >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >> >> > > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > > > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000305680.html Choice - BLOB: Use a CLOB or BLOB column for the entire XML document. MySQL has a maximum of 1 or 2 GIG there. Then process in memory using XSLT, XQuery or what have you (Saxon 9). Extract index values to other columns as necessary to make selective loading faster. Choice - Package: Buy something that does this slice and dice for you. Perhaps Progress/DataDirect has something. Choice - XML column: Create a column of XML type in DB2 or Oracle and do an XQuery on that column. Choice - get MS SQL Server. I think their first approach at supporting XML was to slice and dice - may still be that way. From what I can tell Microsoft's approach was clumsy for alot of uses. Choice - Native XML database. You will have to decide which of these to do given your requirements. -----Original Message----- From: Michael Sokolov [mailto:sokolov@ifactory.com] Sent: Thursday, October 29, 2009 7:42 PM To: 'Fraser Goffin'; xml-dev@lists.xml.org Subject: RE: [xml-dev] Shredding XML I spent a little while evaluating DB-2 and Oracle XQuery implementations - didn't go so far as to implement a full-blown system though, I guess because nobody was holding a gun to my head. The whole automated shredding approach strikes me as totally unworkable for data with any complexity (think about David Lee's 80 table joins), and unneccessary for simple data, where you might as well map by hand. One complication is that a schema is absolutely required, and if the schema changes, you need to re-run the entire table generation process. When I checked, it was looking like it could be quite complex to retain data in such a case: there didn't seem to be the ability to generate incremental schema change operations, so probably it would be necessary to migrate data from an old set of tables to a new set (with the same names!). Then I considered the approach of storing an XML blob or two attached to a metatdata record. I could tell it would have been possible to implement, and we probably could have gotten it working with some reasonable computational efficiency in the end system. However the programming environment was looking very hostile: there are uncomfortable lexical issues that arise when embedding XQuery in SQL or vice versa, and the idea of passing values back and forth between the two different type systems was making me uneasy. I also found that the full text support (which for me is absolutely critical) in DB-2 was lacking - when I checked they were in the midst of a transition from an older, imperfect but functioning system to a newer, but less functional one; the situation with full text is probably better in Oracle; I didn't dig deep enough to find out details. It does sound as if your data may be more record-oriented than mine, which is almost always documents written in English or some natural language, with tagging to make it at least somewhat machine-friendly. So, as Michael Kay said, if it's *already* record-oriented data that has just been wrapped up in angle brackets, you might not run into these problems. -Mike > -----Original Message----- > From: Fraser Goffin [mailto:goffinf@googlemail.com] > Sent: Thursday, October 29, 2009 5:20 PM > To: xml-dev@lists.xml.org > Subject: [xml-dev] Shredding XML > > This list has been unusually quiet of late so I thought it > might be an opportune moment to ask for opinions on the > subject of decomposing XML into relational databases, often > referred to as 'shredding'. > > My particular interest is related to some work I'm currently > engaged in. The basics are we receive XML messages from an > external trading partner and process those messages, > enriching and routing to a number of internal subscriber > applications. One of these applications is MI and the deal > here is that they want the data to been put into a relational > database so that they can create a number of interfaces > 'files' which are sent to still more applications. > > Whilst I would like to consider a pure XML database or even > use some of the XML features that are increasingly prevalent > in mainstream DB vendor products, clearly putting data into a > 'staging' database is one thing, but the capabilities and > competances of the applications and application programmers > who want to retrieve it is a key factor. So, for the > immediate term I might be stuck (if thats fair - probably > not) with relational. > > So to better inform myself and maybe help the debate along > internally, I am interested in anyone else experience good > and bad, of shredding XML data, pitfalls, things to be aware > of, good approaches, when to really not do it. All thoughts > are welcome. > > I find it intersting the some of the 'big boys' are at least > giving the appearance of providing first-class support for > XML both in terms of storage options and manipulation > capability. IBM for example has pureXML. I haven't used these > enough to know if they're just a thin veneer of whether they > have real substance and depth, so again your experiences are welcome. > > Regards > > Fraser, > > ______________________________________________________________ > _________ > > XML-DEV is a publicly archived, unmoderated list hosted by > OASIS to support XML implementation and development. To > minimize spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org List archive: > http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000305659.html XML Prague 2010 Call for Papers XML Prague 2010 is now welcoming submissions for presentations on the following topics: * XML lifecycle (diffing, merging, change tracking, etc.) * Efficiency and performance in XML (verbosity, processing, overuse) * Hypermedia in XML (SMIL, SVG animations) * Spatial data and XML (WGS84, microformats) * XML all the time (XRX, XQuery web applications) All proposals will be submitted for review by a peer review panel made up of the XML Prague Organizing Committee. Submissions will be chosen based on interest, applicability, technical merit, and technical correctness. Accepted Papers will be included inside the published conference proceedings. Authors should strive to contain original material and belong in the topics previously listed. Submissions which can be construed as product or service descriptions (adverts) will probably be deemed inappropriate. Other approaches such as using case studies are welcome but must be clearly related to conference topics. Selected presenters must submit an full paper (on time) and give their presentation and answer questions in English, as well as follow the XML Prague 2010 conference guidelines. Important Dates: * December 21st - End of CFP (extended abstract or full paper) * January 6th - Notification of acceptance/rejection of paper to authors * January 22nd - Final paper How to Submit: All submissions must be done using the conference management system available at https://cmt.research.microsoft.com/XML2010/ If you have never used this system before for other conferences, you will have to sign-up first and create new account for yourself. After logging onto conference management system you will be able to submit your paper and edit this submission before deadline. You can also review the status of your paper as well as review comments from review process. You may submit an abstract or a full paper. We recommend to provide as much information as possible to give the reviewers the best chance to judge your submission. Submission Guidelines: All submissions must be in English and paper should not exceed 15 pages in length. Papers for review can be submitted in any common format. However, we remind people that if your paper is accepted that we will be asking for the final version to be submitted in DocBook XML format. If you have any question regarding submission process please contact Jirka Kosek at jirka.kosek@xmlprague.cz. on behalf, XML Prague Committee ------------------------- Jim Fuller http://www.xmlprague.cz _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000305632.html [ANN] XML Prague 2010, March 13th & 14th ' Temporal XML' XML Prague is a conference on XML for developers, markup geeks, information managers, and students, in its 5th year. To obtain more information or register please visit the website http://www.xmlprague.cz ---------------------------------------- Important Dates ---------------------------------------- * Oct 2009 - Topics Announced, Registration Opens * Oct 2009 - Call for Papers * March 13th & 14th 2010 - XML Prague Conference A separate email will go out today with CFP details. ---------------------------------------- Topics ---------------------------------------- XML Prague 2010 will focus on core and emerging XML technologies with this year's special focus given on temporal aspects of XML. * XML Lifecycle (diffing, merging, change tracking, etc.) * Efficiency and performance in XML (verbosity, processing, overuse) * Hypermedia in XML (SMIL, SVG animations) * Spatial data and XML (WGS84, microformats) * XML all the time (XRX, XQuery web applications) Special panel discussion: Editing XML (open to sponsors) If you have any questions please email us at info@xmlprague.cz. ---------------------------------------- Pricing ---------------------------------------- * Conference Pass (25 EUR, 30 EUR on site):* - Access to all XML Prague 2009 conference sessions (13 - 14 March). - Coffee and light refreshments during coffee-breaks (4 times). - A copy of conference proceedings. * Full Pass (60 EUR):* - All included in the Conference package, - plus two lunches (13 - 14 March) and the social dinner (13 March). *Social Dinner (20 EUR)* - the social dinner (13 March) for accompanying person. ---------------------------------------- Location ---------------------------------------- The conference is held in Prague, Czech Republic. Lesser Town Campus of Charles University Malostranské námÄ›stí 25, Prague, Czech Republic ---------------------------------------- How to Participate ---------------------------------------- If you are planning to attend the conference and would be interested in participating, please review the available options. * Poster: Submit a 'poster' submission which if we have time may also mean giving a 5 minute Lightening Talk. * Workshops: As we have limited resources please contact us early to discuss the possibility of holding a workshop. Submit your ideas to ideas@xmlprague.cz ---------------------------------------- XML Prague 2009 Organizing Committee ---------------------------------------- Petr Cimprich, Unity Mobile Tomáš Kaiser, University of West Bohemia, Pilsen Jaroslav NeÅ¡etÅ™il, Charles University, Prague James Fuller, http://www.webcomposite.com Jirka Kosek, xmlguru.cz & University of Economics, Prague Mohamed Zergaoui, Innovimax Pavel Kroh, Independent Consultant Martin Žák Vit Janota ---------------------------------------- Hope to see everyone there. XML Prague Committee ------------------------- Jim Fuller XML Prague 2010 http://www.xmlprague.cz _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000305631.html I spent a little while evaluating DB-2 and Oracle XQuery implementations - didn't go so far as to implement a full-blown system though, I guess because nobody was holding a gun to my head. The whole automated shredding approach strikes me as totally unworkable for data with any complexity (think about David Lee's 80 table joins), and unneccessary for simple data, where you might as well map by hand. One complication is that a schema is absolutely required, and if the schema changes, you need to re-run the entire table generation process. When I checked, it was looking like it could be quite complex to retain data in such a case: there didn't seem to be the ability to generate incremental schema change operations, so probably it would be necessary to migrate data from an old set of tables to a new set (with the same names!). Then I considered the approach of storing an XML blob or two attached to a metatdata record. I could tell it would have been possible to implement, and we probably could have gotten it working with some reasonable computational efficiency in the end system. However the programming environment was looking very hostile: there are uncomfortable lexical issues that arise when embedding XQuery in SQL or vice versa, and the idea of passing values back and forth between the two different type systems was making me uneasy. I also found that the full text support (which for me is absolutely critical) in DB-2 was lacking - when I checked they were in the midst of a transition from an older, imperfect but functioning system to a newer, but less functional one; the situation with full text is probably better in Oracle; I didn't dig deep enough to find out details. It does sound as if your data may be more record-oriented than mine, which is almost always documents written in English or some natural language, with tagging to make it at least somewhat machine-friendly. So, as Michael Kay said, if it's *already* record-oriented data that has just been wrapped up in angle brackets, you might not run into these problems. -Mike > -----Original Message----- > From: Fraser Goffin [mailto:goffinf@googlemail.com] > Sent: Thursday, October 29, 2009 5:20 PM > To: xml-dev@lists.xml.org > Subject: [xml-dev] Shredding XML > > This list has been unusually quiet of late so I thought it > might be an opportune moment to ask for opinions on the > subject of decomposing XML into relational databases, often > referred to as 'shredding'. > > My particular interest is related to some work I'm currently > engaged in. The basics are we receive XML messages from an > external trading partner and process those messages, > enriching and routing to a number of internal subscriber > applications. One of these applications is MI and the deal > here is that they want the data to been put into a relational > database so that they can create a number of interfaces > 'files' which are sent to still more applications. > > Whilst I would like to consider a pure XML database or even > use some of the XML features that are increasingly prevalent > in mainstream DB vendor products, clearly putting data into a > 'staging' database is one thing, but the capabilities and > competances of the applications and application programmers > who want to retrieve it is a key factor. So, for the > immediate term I might be stuck (if thats fair - probably > not) with relational. > > So to better inform myself and maybe help the debate along > internally, I am interested in anyone else experience good > and bad, of shredding XML data, pitfalls, things to be aware > of, good approaches, when to really not do it. All thoughts > are welcome. > > I find it intersting the some of the 'big boys' are at least > giving the appearance of providing first-class support for > XML both in terms of storage options and manipulation > capability. IBM for example has pureXML. I haven't used these > enough to know if they're just a thin veneer of whether they > have real substance and depth, so again your experiences are welcome. > > Regards > > Fraser, > > ______________________________________________________________ > _________ > > XML-DEV is a publicly archived, unmoderated list hosted by > OASIS to support XML implementation and development. To > minimize spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org List archive: > http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000305610.html > --> Liam Says ... > Yes, this is what I recommended in a book on the subject, years ago, > and is what generally works the best. > > >> 2) Put XML in "Blob" fields >> --> solves the "letter of the law" -- yea its in "A Relational Database" >> but its useless >> > > If the purpose (as so often) of the relational database is warm fuzzies, > it's far from useless. Plus it'll use massively more disk storage! :-) > > I was only slightly serious when I said it was "useless". I have implemented quite functional and useful systems using this approach (storing xml as a blob field). It works and performs extremely well ... as long as you don't try to use the blob field in an SQL Query ... Rather, load the field as a blob into the application memory and perform your XML operations there. I have found that this can perform 100's (or more) of times more efficiently then performing similar operations on the server using relational data ... providing you have enough memory and the processing is localized. In one example, I had an xml schema with about 50 distinct elements. We did an experiment of shredding this into relational data, which turned into about 80 tables. Performing joins across 80 tables was dismal, even when done as a stored procedure (in an enterprise DB no less). However the analogous operation of loading the entire "blob" into memory on the client, then parsing it as XML then using java XML operations on the data (and in this case we were writing it back out) performed vastly (100x+) better and was much simpler to code. I do recommend this approach if your xml data is localized, and can fit into memory, and doesn't need to be deeply queried from SQL. You do gain some advantages of a relational DB - namely the consistency of storage, backups and data management. And you can tell everyone "Its in the database" ... (then duck). -David lee dlee@calldei.com www.xmlsh.org]]> http://www.altova.com/list/xml-dev/200910/msg1000305606.html On Thu, Oct 29, 2009 at 05:36:33PM -0400, David A. Lee wrote: > Ron Bourret has some excellent references here > http://www.rpbourret.com/xml/XMLDBLinks.htm#Relational > [...] > > I've been faced with this problem myself on multiple occasions where the > organization is not very XML friendly and "needs" the data in a > relational DB and inevitably the solution has been > > 1) Dont do it. > --> XML ended up in files , sometimes a DB table with top level topics > or some basic metadata only. Yes, this is what I recommended in a book on the subject, years ago, and is what generally works the best. > 2) Put XML in "Blob" fields > --> solves the "letter of the law" -- yea its in "A Relational Database" > but its useless If the purpose (as so often) of the relational database is warm fuzzies, it's far from useless. Plus it'll use massively more disk storage! :-) > 3) Its a royal PITA > A shredding can end up with about 2x the # of distinct elements into > tables. Handling mixed content is excruciatingly painful. > Doing a good job usually ends up with relational data thats almost > impossible to access relationally. I remember waiting 45 minutes for such a system (on a high-end server) to reconstitute a 5 megabyte SGML document... but they were complex documents, aircraft manuals, with often dozens of attributes for a single element. XML is all about sequence, containment, and unbounded-length text, none of which are an ideal fit for SQL, although there are SQL extensions for each of them. So he best thing is to work out what you actually need for your SQL queries, and to split tha up and put it in the relational database, and ot leave the documents out in the file system, but, managed by a server process so that users can't rename them or change them without telling the database. Frankly, if they are using Oracle or DB2 or SQL Server, put the data into a blob of type XML, and you can use XPath on it, and XQuery, efficiently, directly from SQL, with most people completely unaware of it :-) >> I find it intersting the some of the 'big boys' are at least giving >> the appearance of providing first-class support for XML both in terms >> of storage options and manipulation capability. IBM for example has >> pureXML. I haven't used these enough to know if they're just a thin >> veneer of whether they have real substance and depth, so again your >> experiences are welcome. They have real substance and detph. All the major databases are supporting XQuery, and supporting it directly, not as a layer on top of SQL. It's being used in production, with large databases, in real commercial environments. Liam -- Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/ http://www.holoweb.net/~liam/ * http://www.fromoldbooks.org/ _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000305603.html > My particular interest is related to some work I'm currently > engaged in. The basics are we receive XML messages from an > external trading partner and process those messages, > enriching and routing to a number of internal subscriber > applications. One of these applications is MI and the deal > here is that they want the data to been put into a relational > database so that they can create a number of interfaces > 'files' which are sent to still more applications. > > Whilst I would like to consider a pure XML database or even > use some of the XML features that are increasingly prevalent > in mainstream DB vendor products, clearly putting data into a > 'staging' database is one thing, but the capabilities and > competances of the applications and application programmers > who want to retrieve it is a key factor. So, for the > immediate term I might be stuck (if thats fair - probably > not) with relational. If the XML is just a CSV file, then by all means shove it into a table in a relational database. If it's anything more complicated, don't even think about shredding it by hand: it will be a nightmare. Especially if you have doubts about the intellectual capabilities of the programmers who are going to have to deal with it. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000305599.html It surely is a little bit of overhead, but you can work with very large xml files. Take a look at the XPath Accelerator encoding (so you can also map XPath queries to SQL queries and enhance the whole thing with staircase join and so on to gain performance benefits). Also tree knowledge can be exploited to a great extend. The DBIS group at the university of constanze has built a native open-source XML database, where this knowledge is incorporated (BaseX.org). Basically you can use SAX to parse the xml files and create a table based on the XPath Accellerator scheme. hth, Johannes _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000305598.html Ron Bourret has some excellent references here http://www.rpbourret.com/xml/XMLDBLinks.htm#Relational I took a 1 day class from him years ago in which he covered the topic very well. I suggest its too big a topic for an email discussion. I've been faced with this problem myself on multiple occasions where the organization is not very XML friendly and "needs" the data in a relational DB and inevitably the solution has been 1) Dont do it. --> XML ended up in files , sometimes a DB table with top level topics or some basic metadata only. 2) Put XML in "Blob" fields --> solves the "letter of the law" -- yea its in "A Relational Database" but its useless 3) Its a royal PITA A shredding can end up with about 2x the # of distinct elements into tables. Handling mixed content is excruciatingly painful. Doing a good job usually ends up with relational data thats almost impossible to access relationally. But it all really depends on how complicated your XML is. If its dirt simple XML then shredding it may work fine for you. David A. Lee dlee@calldei.com http://www.calldei.com http://www.xmlsh.org 812-482-5224 Fraser Goffin wrote: > This list has been unusually quiet of late so I thought it might be an > opportune moment to ask for opinions on the subject of decomposing XML > into relational databases, often referred to as 'shredding'. > > My particular interest is related to some work I'm currently engaged > in. The basics are we receive XML messages from an external trading > partner and process those messages, enriching and routing to a number > of internal subscriber applications. One of these applications is MI > and the deal here is that they want the data to been put into a > relational database so that they can create a number of interfaces > 'files' which are sent to still more applications. > > Whilst I would like to consider a pure XML database or even use some > of the XML features that are increasingly prevalent in mainstream DB > vendor products, clearly putting data into a 'staging' database is one > thing, but the capabilities and competances of the applications and > application programmers who want to retrieve it is a key factor. So, > for the immediate term I might be stuck (if thats fair - probably not) > with relational. > > So to better inform myself and maybe help the debate along internally, > I am interested in anyone else experience good and bad, of shredding > XML data, pitfalls, things to be aware of, good approaches, when to > really not do it. All thoughts are welcome. > > I find it intersting the some of the 'big boys' are at least giving > the appearance of providing first-class support for XML both in terms > of storage options and manipulation capability. IBM for example has > pureXML. I haven't used these enough to know if they're just a thin > veneer of whether they have real substance and depth, so again your > experiences are welcome. > > Regards > > Fraser, > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000305588.html This list has been unusually quiet of late so I thought it might be an opportune moment to ask for opinions on the subject of decomposing XML into relational databases, often referred to as 'shredding'. My particular interest is related to some work I'm currently engaged in. The basics are we receive XML messages from an external trading partner and process those messages, enriching and routing to a number of internal subscriber applications. One of these applications is MI and the deal here is that they want the data to been put into a relational database so that they can create a number of interfaces 'files' which are sent to still more applications. Whilst I would like to consider a pure XML database or even use some of the XML features that are increasingly prevalent in mainstream DB vendor products, clearly putting data into a 'staging' database is one thing, but the capabilities and competances of the applications and application programmers who want to retrieve it is a key factor. So, for the immediate term I might be stuck (if thats fair - probably not) with relational. So to better inform myself and maybe help the debate along internally, I am interested in anyone else experience good and bad, of shredding XML data, pitfalls, things to be aware of, good approaches, when to really not do it. All thoughts are welcome. I find it intersting the some of the 'big boys' are at least giving the appearance of providing first-class support for XML both in terms of storage options and manipulation capability. IBM for example has pureXML. I haven't used these enough to know if they're just a thin veneer of whether they have real substance and depth, so again your experiences are welcome. Regards Fraser, _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000305587.html Xerces-J is also implementing XML Schema 1.1. Planning to have a preview release with partial support at the end of the year, though you could try out the current development stream [1] today if you're feeling adventurous. [1] http://svn.apache.org/viewvc/xerces/java/branches/xml-schema-1.1-dev/ Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@ca.ibm.com E-mail: mrglavas@apache.org mozer <xmlizer@gmail.com> wrote on 10/29/2009 01:46:19 AM: > Go and take a look at Saxon EE (see > http://www.saxonica.com/feature-matrix.html ) > > Xmlizer > > > > On Wed, Oct 28, 2009 at 3:57 PM, Olivier Rossel > <olivier.rossel@gmail.com> wrote: > > > > It seems that XML Schema provides many new ways to validate XML documents. > > I was wondering about the status of reference implementations? > > Can we currently play with one of them? > > > > _______________________________________________________________________ > > > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > > to support XML implementation and development. To minimize > > spam in the archives, you must subscribe before posting. > > > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > > subscribe: xml-dev-subscribe@lists.xml.org > > List archive: http://lists.xml.org/archives/xml-dev/ > > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000305584.html Altova is pleased to announce general availability version 2010 of its MissionKit XML, database, and UML tools. v2010 is our MOST WANTED release and includes over 70 new customer-requested features. Just a few of these include: * Support for WSDL 2.0, JSON, and SysML technologies * New stylesheet design paradigm with advanced support for electronic form design * Enhanced XBRL functionality * Database schema comparison * And much more More info and screenshots are available at <http://www.altova.com/whatsnew.html> Download a fully functional free trial at <http://www.altova.com/download.html> Best regards, Liz Liz Andrews Technical Marketing Manager Altova, Inc. www.altova.com ________________________________ This e-mail and any attachments are intended only for the person/entity to which they are addressed and may contain confidential and/or privileged material. If you received this in error, please notify the sender and delete the message.]]> http://www.altova.com/list/xml-dev/200910/msg1000305580.html Go and take a look at Saxon EE (see http://www.saxonica.com/feature-matrix.html ) Xmlizer On Wed, Oct 28, 2009 at 3:57 PM, Olivier Rossel <olivier.rossel@gmail.com> wrote: > > It seems that XML Schema provides many new ways to validate XML documents. > I was wondering about the status of reference implementations? > Can we currently play with one of them? > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000305526.html It seems that XML Schema provides many new ways to validate XML documents. I was wondering about the status of reference implementations? Can we currently play with one of them? _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000305484.html Michael Kay schrieb: >> So the correct assert would be inside the cd element: >> >> <xs:element name="cd"> >> <xs:complexType> >> <xs:sequence> >> <xs:element ref="pd" minOccurs="1" maxOccurs="unbounded"/> >> <xs:element ref="segs"/> >> </xs:sequence> >> <xs:assert test="pd/@start le segs/s/@start"/> >> <xs:assert test="pd/@end ge segs/s/@end"/> >> </xs:complexType> >> </xs:element> >> > > Shouldn't it be something like > > test="every $s in segs/s/@start satisfies pd/@start le $s" > >> In addition the problem with that solution is that the error >> is raised for the common ancestor which makes it much harder >> to inspect the wrong s element (if I imagine hundreds of s >> elements and only one is wrong...) > > Yes. Saxon supports a coding convention here: if you write the assertion as > an "empty()" predicate, and the result isn't empty, Saxon will tell you > where the nodes were that were found. Something like: > > test="empty(for $p in pd/@start, $s in segs/s[$p le @start] return $s)" Perfect. This works like a charm. Again, thank you very much. Best, Maik Stührenberg > > Regards, > > Michael Kay > http://www.saxonica.com/ > http://twitter.com/michaelhkay > > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000305167.html > > So the correct assert would be inside the cd element: > > <xs:element name="cd"> > <xs:complexType> > <xs:sequence> > <xs:element ref="pd" minOccurs="1" maxOccurs="unbounded"/> > <xs:element ref="segs"/> > </xs:sequence> > <xs:assert test="pd/@start le segs/s/@start"/> > <xs:assert test="pd/@end ge segs/s/@end"/> > </xs:complexType> > </xs:element> > Shouldn't it be something like test="every $s in segs/s/@start satisfies pd/@start le $s" > > In addition the problem with that solution is that the error > is raised for the common ancestor which makes it much harder > to inspect the wrong s element (if I imagine hundreds of s > elements and only one is wrong...) Yes. Saxon supports a coding convention here: if you write the assertion as an "empty()" predicate, and the result isn't empty, Saxon will tell you where the nodes were that were found. Something like: test="empty(for $p in pd/@start, $s in segs/s[$p le @start] return $s)" Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000305166.html Hello Michael, thank you very much for the quick response. Michael Kay schrieb: >> <xs:complexType> >> <xs:attribute name="start" type="xs:integer" use="required"/> >> <xs:attribute name="end" type="xs:integer" use="required"/> >> <xs:assert test="@start ge root(.)/cd/pd/@start"/> >> <xs:assert test="@end le root(.)/cd/pd/@end"/> >> </xs:complexType> > > xs:assert sees a tree fragment rooted at the element E whose type you are > testing against. root(.) returns the root of this tree, that is, the element > E. The idea is that validation of an element depends only on the content of > that element, not on the context in which it appears. XSLT, for example, > assumes that if you copy a valid element to a new tree, then it will still > be valid (against the original type). > >> What I want is to assert that the value of the start >> attribute of each s element is greater or equal than that of >> the start attribute of the pd element (and vice versa for the >> end attribute). >> Thanks for the clarification, I guess I have to read the specs more thoroughly. > > You need to put the assertion at the level of the common ancestor: that is, > identify the element that contains all the data needed to compute the > assertion, and put the assertion on the type of that element. That was an idea I had in mind, but I wasn't sure if the @test XPath expression would really test for every single s child of segs. So the correct assert would be inside the cd element: <xs:element name="cd"> <xs:complexType> <xs:sequence> <xs:element ref="pd" minOccurs="1" maxOccurs="unbounded"/> <xs:element ref="segs"/> </xs:sequence> <xs:assert test="pd/@start le segs/s/@start"/> <xs:assert test="pd/@end ge segs/s/@end"/> </xs:complexType> </xs:element> But if I try that I still get two validation errors: Element cd does not satisfy assertion pd/@end ge segs/s/@end Element cd does not satisfy assertion pd/@start le segs/s/@start I understand and agree that the value of the s/end attribute raises the error but why does the start attribute's value? In addition the problem with that solution is that the error is raised for the common ancestor which makes it much harder to inspect the wrong s element (if I imagine hundreds of s elements and only one is wrong...) -- which was a reason why I tried to locate the assert elements underneath the s element. Again, thank you very much for your hints. Best regards, Maik Stührenberg > > Regards, > > Michael Kay > http://www.saxonica.com/ > http://twitter.com/michaelhkay > > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000305165.html > <xs:complexType> > <xs:attribute name="start" type="xs:integer" use="required"/> > <xs:attribute name="end" type="xs:integer" use="required"/> > <xs:assert test="@start ge root(.)/cd/pd/@start"/> > <xs:assert test="@end le root(.)/cd/pd/@end"/> > </xs:complexType> xs:assert sees a tree fragment rooted at the element E whose type you are testing against. root(.) returns the root of this tree, that is, the element E. The idea is that validation of an element depends only on the content of that element, not on the context in which it appears. XSLT, for example, assumes that if you copy a valid element to a new tree, then it will still be valid (against the original type). > > What I want is to assert that the value of the start > attribute of each s element is greater or equal than that of > the start attribute of the pd element (and vice versa for the > end attribute). > You need to put the assertion at the level of the common ancestor: that is, identify the element that contains all the data needed to compute the assertion, and put the assertion on the type of that element. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000305164.html Hello everyone, since I'm trying to convert an XSD 1.0 + embedded Schematron schema into an XSD 1.1 schema I stumbled upon an error regarding an assert element. I tried to read all the questions raised (and answered) on this list regarding this topic so far without success. So if there was a discussion already some time ago just give me a quick note when and I will help myself with the list archive. Here is a very simple schema demonstrating the problem (at least I hope it does): <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.example.org" targetNamespace="http://www.example.org"> <xs:element name="cd"> <xs:complexType> <xs:sequence> <xs:element ref="pd" minOccurs="1" maxOccurs="unbounded"/> <xs:element ref="segs"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="pd"> <xs:complexType mixed="true"> <xs:attribute name="start" type="xs:integer" use="required"/> <xs:attribute name="end" type="xs:integer" use="required"/> </xs:complexType> </xs:element> <xs:element name="segs"> <xs:complexType> <xs:sequence> <xs:element ref="s" minOccurs="1" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="s"> <xs:complexType> <xs:attribute name="start" type="xs:integer" use="required"/> <xs:attribute name="end" type="xs:integer" use="required"/> <xs:assert test="@start ge root(.)/cd/pd/@start"/> <xs:assert test="@end le root(.)/cd/pd/@end"/> </xs:complexType> </xs:element> </xs:schema> The pd element has two integer attributes, start and end. The s element which may occur several times as a child/children of the segs element (which itself is a sibling of the before mentioned pd element) bears the same attributes. What I want is to assert that the value of the start attribute of each s element is greater or equal than that of the start attribute of the pd element (and vice versa for the end attribute). Saxon-EE 9.2.0.2 states that the schema itself is correct. I use a simple demo instance for testing my two assert elements: <?xml version="1.0" encoding="UTF-8"?> <cd xmlns="http://www.example.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.example.org demo.xsd"> <pd start="0" end="10"/> <segs> <s start="0" end="5"/> <s start="1" end="15"/> </segs> </cd> If my asserts are correct (which I doubt) then in my opinion the first s element should be fine while the second element's end attribute should raise a validation error. Saxon-EE 9.2.0.2 reports four validation errors in total: Element s does not satisfy assertion @start ge root(.)/cd/pd/@start Element s does not satisfy assertion @end le root(.)/cd/pd/@end Element s does not satisfy assertion @start ge root(.)/cd/pd/@start Element s does not satisfy assertion @end le root(.)/cd/pd/@end So as already stated my questions are as following: - I assume I made a mistake in creating my assert elements (at least the test XPath expression), if anyone could give me a hint I would be very grateful. - Just as a comprehension question since all examples I've seen so far are created in respect to local asserts: Is it possible to create such a constraint depending on an element (either complex or simple type) created globally somewhere else (e.g. in the same schema instance or in an external schema file which is imported or included)? Or is this out of scope for XSD 1.1? Best regards, Maik Stührenberg _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000305163.html Fellow XML-Dev'ers, OASIS has opened a 60-day public review of the new context/value association for genericode file format: http://lists.oasis-open.org/archives/codelist/200910/msg00005.html Comments are most welcome and are sent to: http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=codelist Code lists and identifier lists are examples of controlled vocabularies of values (e.g. currency codes, country codes, product identifiers, etc.) For some communities of users (e.g. those with business-oriented XML documents) the management of controlled vocabularies presents particular challenges for document modeling. While communities may standardize document structures, trading partners within the community have their own constraints that may change on an hourly basis yet must work within the community framework. List-level and value-level metadata for controlled vocabularies are managed using the OASIS genericode file format, published in 2007: http://docs.oasis-open.org/codelist/genericode For data entry by the sender, the appropriate lists of values and mechanisms for disambiguation need to be well-defined for the proper semantics to be represented. For validation by the receiver, the same lists and disambiguation ensures the proper semantics are interpreted. That disambiguation is done through attributes or elements associated with the controlled vocabulary information items. Simple schema language enumerations are insufficient to the task of associating instance-level metadata and the extension and restriction of controlled vocabularies to meet business needs. Instance-level metadata for the application of controlled vocabularies to XML document structures is expressed using the OASIS context/value association using genericode specification being announced for public review. The members of the committee look forward to any comments you may have on the file format itself, sent through the formal OASIS channels (any comments on the validation or visualization or training cited below are to be sent to me privately please). Thank you! . . . . . . . . . . . Ken Chairman, OASIS Code List Representation Technical Committee cc: CLR-Dev, UBL-Dev, XML-Dev p.s. A Schematron-based implementation of OASIS context/value association is freely available to experiment with or deploy these file formats for validation: http://www.CraneSoftwrights.com/resources/ubl/index.htm#cva2sch Visualization stylesheets for these file formats are freely available: http://www.CraneSoftwrights.com/resources/ubl/index.htm#codess p.p.s. A full-day hands-on training class on both these file formats is being commercially offered in Copenhagen this coming Tuesday, please see here for details: http://www.CraneSoftwrights.com/index.html#Crane200910CPH -- Upcoming: hands-on code list, UBL, XSLT, XQuery and XSL-FO classes in Copenhagen Denmark and Washington DC USA, October/November 2009 Interested in other classes? http://www.CraneSoftwrights.com/x/i/ Crane Softwrights Ltd. http://www.CraneSoftwrights.com/x/ Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video Video lesson: http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18 Video overview: http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18 G. Ken Holman mailto:gkholman@CraneSoftwrights.com Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/x/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304967.html The Topic Maps Research and Applications conference ======================================================= November 11-13 this year we are arranging the fifth TMRA conference in Leipzig, Germany on all aspects of Topic Maps. This year's conference theme is "Linked Topic Maps", emphasizing how the linked data movement and the Topic Maps community share a common goal. This year's conference has a particularly strong program, starting off with a keynote by Michael Sperberg-McQueen (co-editor of the XML Recommendation, among other things), and closing with a keynote by Steven R. Newcomb, the inventor of Topic Maps. Some items from the program: - Creating Topic Maps Ontologies for Space Experiments - Integrating SAP and Sharepoint using Semantic Technologies - tolog updates, an update language for Topic Maps - Subj3ct.com - a search service for linked data identifiers - H-Maps: A New Approach for Efficient Graphical Visualization and Navigation of Topic Maps For more information, see http://www.tmra.de/2009/ The city of Leipzig is renowned for its culture (particularly the Gewandhausorchester Leipzig), as well as for the local beer speciality: Gose, or Gosebier, which you can sample just 2 minutes walk from the Villa Ida conference center. We hope to see you in Leipzig in November! --Lars M. http://www.garshol.priv.no/tmphoto/ http://www.garshol.priv.no/blog/ _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304950.html Olivier Rossel a écrit : > that sounds very cool. > The only missing part is how not to hardcode the values for in.xml and > out.xml in the file, but provide them from the command line. Use the SYSTEM module for that purpose: <xcl:active-sheet xmlns:xcl="http://ns.inria.org/active-tags/xcl" xmlns:sys="http://ns.inria.org/active-tags/sys"> change <xcl:parse name="input" source="in.xml" style="stream"/> with: <xcl:parse name="input" source="{ string( $sys:env/in ) }" style="stream"/> and change: <xcl:transform source="{ $included }" output="out.xml"/> with: <xcl:transform source="{ $included }" output="{ string( $sys:env/out ) }"/> and supply the "in" and "out" system parameters when running: java -Din=in.xml -Dout=out.xml -jar reflex-0.4.0.jar run inclusion.xcl > > On Friday, October 16, 2009, Philippe Poulard > <philippe.poulard@sophia.inria.fr> wrote: >> Olivier Rossel a écrit : >> >> philippe, >> could you please provide a small example (command line, or java code >> snippet) about how to >> print a self contained document from a document that contains some xincludes? >> >> >> Hi Olivier, >> >> -download RefleX and unzip >> java -jar reflex-0.4.0.jar run inclusion.xcl >> >> -inclusion.xcl: >> <?xml version="1.0" encoding="iso-8859-1"?> >> <xcl:active-sheet xmlns:xcl="http://ns.inria.org/active-tags/xcl"> >> <!--get an XInclude filter--> >> <xcl:parse-filter name="xinclude" source="http://www.w3.org/2001/XInclude"/> >> <!--connect a pipeline--> >> <xcl:parse name="input" source="in.xml" style="stream"/> >> <xcl:filter name="included" source="{ $input }" filter="{ $xinclude }"/> >> <!--transform SAX to XML--> >> <xcl:transform source="{ $included }" output="out.xml"/> >> </xcl:active-sheet> >> -An XInclude filter is just a special filter; you can also use other filters with <xcl:parse-filter> as explained here: >> http://reflex.gforge.inria.fr/tutorial-pipelinesAndFilters.html >> >> -in.xml: >> <?xml version="1.0" encoding="iso-8859-1"?> >> <root xmlns:xi="http://www.w3.org/2001/XInclude"> >> <xi:include href="alternate.xml" parse="xml" xpointer="xpointer(/inside/insideItr/text())"/> >> </root> >> >> -alternalte.xml: >> <?xml version="1.0" encoding="iso-8859-1"?> >> <inside> >> <insideItr>waza</insideItr> >> </inside> >> >> -out.xml: >> <?xml version="1.0" encoding="UTF-8"?> >> <root xmlns:xi="http://www.w3.org/2001/XInclude" xml:base="file:///path/to/in.xml"> >> waza >> </root> >> >> you'll find another example here: >> http://reflex.gforge.inria.fr/tutorial-basics.html#dtdValidation >> >> >> >> On Thu, Oct 15, 2009 at 10:53 AM, Philippe Poulard >> <philippe.poulard@sophia.inria.fr> wrote: >> >> Olivier Rossel a écrit : >> >> short answer (from the support team of Altova) : it might exist in a >> future version. >> >> xerces supports xinclude, but i don't know if xpointer() is supported >> >> RefleX supports the xpointer() scheme as long as you use only XPath >> expressions (don't use xpointer points and ranges); of course it works in >> DOM-parsing style, but also in SAX-parsing style if your XPath expressions >> don't have to look backwards >> >> have a look at what is supported here: >> http://reflex.gforge.inria.fr/tests-xinclude.html >> >> -- >> Cordialement, >> >> /// >> (. .) >> --------ooO--(_)--Ooo-------- >> | Philippe Poulard | >> ----------------------------- >> http://reflex.gforge.inria.fr/ >> Have the RefleX ! >> >> >> >> >> -- >> Cordialement, >> >> /// >> (. .) >> --------ooO--(_)--Ooo-------- >> | Philippe Poulard | >> ----------------------------- >> http://reflex.gforge.inria.fr/ >> Have the RefleX ! >> > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > -- Cordialement, /// (. .) --------ooO--(_)--Ooo-------- | Philippe Poulard | ----------------------------- http://reflex.gforge.inria.fr/ Have the RefleX ! _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304948.html that sounds very cool. The only missing part is how not to hardcode the values for in.xml and out.xml in the file, but provide them from the command line. On Friday, October 16, 2009, Philippe Poulard <philippe.poulard@sophia.inria.fr> wrote: > Olivier Rossel a écrit : > > philippe, > could you please provide a small example (command line, or java code > snippet) about how to > print a self contained document from a document that contains some xincludes? > > > Hi Olivier, > > -download RefleX and unzip > java -jar reflex-0.4.0.jar run inclusion.xcl > > -inclusion.xcl: > <?xml version="1.0" encoding="iso-8859-1"?> > <xcl:active-sheet xmlns:xcl="http://ns.inria.org/active-tags/xcl"> >    <!--get an XInclude filter--> >    <xcl:parse-filter name="xinclude" source="http://www.w3.org/2001/XInclude"/> >    <!--connect a pipeline--> >    <xcl:parse name="input" source="in.xml" style="stream"/> >    <xcl:filter name="included" source="{ $input }" filter="{ $xinclude }"/> >    <!--transform SAX to XML--> >    <xcl:transform source="{ $included }" output="out.xml"/> > </xcl:active-sheet> > -An XInclude filter is just a special filter; you can also use other filters with <xcl:parse-filter> as explained here: > http://reflex.gforge.inria.fr/tutorial-pipelinesAndFilters.html > > -in.xml: > <?xml version="1.0" encoding="iso-8859-1"?> > <root xmlns:xi="http://www.w3.org/2001/XInclude"> >    <xi:include href="alternate.xml" parse="xml" xpointer="xpointer(/inside/insideItr/text())"/> > </root> > > -alternalte.xml: > <?xml version="1.0" encoding="iso-8859-1"?> > <inside> >  <insideItr>waza</insideItr> > </inside> > > -out.xml: > <?xml version="1.0" encoding="UTF-8"?> > <root xmlns:xi="http://www.w3.org/2001/XInclude" xml:base="file:///path/to/in.xml"> >    waza > </root> > > you'll find another example here: > http://reflex.gforge.inria.fr/tutorial-basics.html#dtdValidation > > > > On Thu, Oct 15, 2009 at 10:53 AM, Philippe Poulard > <philippe.poulard@sophia.inria.fr> wrote: > > Olivier Rossel a écrit : > > short answer (from the support team of Altova) : it might exist in a > future version. > > xerces supports xinclude, but i don't know if xpointer() is supported > > RefleX supports the xpointer() scheme as long as you use only XPath > expressions (don't use xpointer points and ranges); of course it works in > DOM-parsing style, but also in SAX-parsing style if your XPath expressions > don't have to look backwards > > have a look at what is supported here: > http://reflex.gforge.inria.fr/tests-xinclude.html > > -- > Cordialement, > >             /// >            (. .) >  --------ooO--(_)--Ooo-------- > |      Philippe Poulard       | >  ----------------------------- >  http://reflex.gforge.inria.fr/ >      Have the RefleX ! > > > > > -- > Cordialement, > >              /// >             (. .) >  --------ooO--(_)--Ooo-------- > |      Philippe Poulard       | >  ----------------------------- >  http://reflex.gforge.inria.fr/ >       Have the RefleX ! > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304947.html Olivier Rossel a écrit : > philippe, > could you please provide a small example (command line, or java code > snippet) about how to > print a self contained document from a document that contains some xincludes? Hi Olivier, -download RefleX and unzip java -jar reflex-0.4.0.jar run inclusion.xcl -inclusion.xcl: <?xml version="1.0" encoding="iso-8859-1"?> <xcl:active-sheet xmlns:xcl="http://ns.inria.org/active-tags/xcl"> <!--get an XInclude filter--> <xcl:parse-filter name="xinclude" source="http://www.w3.org/2001/XInclude"/> <!--connect a pipeline--> <xcl:parse name="input" source="in.xml" style="stream"/> <xcl:filter name="included" source="{ $input }" filter="{ $xinclude }"/> <!--transform SAX to XML--> <xcl:transform source="{ $included }" output="out.xml"/> </xcl:active-sheet> -An XInclude filter is just a special filter; you can also use other filters with <xcl:parse-filter> as explained here: http://reflex.gforge.inria.fr/tutorial-pipelinesAndFilters.html -in.xml: <?xml version="1.0" encoding="iso-8859-1"?> <root xmlns:xi="http://www.w3.org/2001/XInclude"> <xi:include href="alternate.xml" parse="xml" xpointer="xpointer(/inside/insideItr/text())"/> </root> -alternalte.xml: <?xml version="1.0" encoding="iso-8859-1"?> <inside> <insideItr>waza</insideItr> </inside> -out.xml: <?xml version="1.0" encoding="UTF-8"?> <root xmlns:xi="http://www.w3.org/2001/XInclude" xml:base="file:///path/to/in.xml"> waza </root> you'll find another example here: http://reflex.gforge.inria.fr/tutorial-basics.html#dtdValidation > > On Thu, Oct 15, 2009 at 10:53 AM, Philippe Poulard > <philippe.poulard@sophia.inria.fr> wrote: >> Olivier Rossel a écrit : >>> short answer (from the support team of Altova) : it might exist in a >>> future version. >> xerces supports xinclude, but i don't know if xpointer() is supported >> >> RefleX supports the xpointer() scheme as long as you use only XPath >> expressions (don't use xpointer points and ranges); of course it works in >> DOM-parsing style, but also in SAX-parsing style if your XPath expressions >> don't have to look backwards >> >> have a look at what is supported here: >> http://reflex.gforge.inria.fr/tests-xinclude.html >> >> -- >> Cordialement, >> >> /// >> (. .) >> --------ooO--(_)--Ooo-------- >> | Philippe Poulard | >> ----------------------------- >> http://reflex.gforge.inria.fr/ >> Have the RefleX ! >> -- Cordialement, /// (. .) --------ooO--(_)--Ooo-------- | Philippe Poulard | ----------------------------- http://reflex.gforge.inria.fr/ Have the RefleX ! _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304946.html philippe, could you please provide a small example (command line, or java code snippet) about how to print a self contained document from a document that contains some xincludes? On Thu, Oct 15, 2009 at 10:53 AM, Philippe Poulard <philippe.poulard@sophia.inria.fr> wrote: > Olivier Rossel a écrit : >> >> short answer (from the support team of Altova) : it might exist in a >> future version. > > xerces supports xinclude, but i don't know if xpointer() is supported > > RefleX supports the xpointer() scheme as long as you use only XPath > expressions (don't use xpointer points and ranges); of course it works in > DOM-parsing style, but also in SAX-parsing style if your XPath expressions > don't have to look backwards > > have a look at what is supported here: > http://reflex.gforge.inria.fr/tests-xinclude.html > > -- > Cordialement, > >              /// >             (. .) >  --------ooO--(_)--Ooo-------- > |      Philippe Poulard       | >  ----------------------------- >  http://reflex.gforge.inria.fr/ >       Have the RefleX ! > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304939.html Olivier Rossel a écrit : > short answer (from the support team of Altova) : it might exist in a > future version. xerces supports xinclude, but i don't know if xpointer() is supported RefleX supports the xpointer() scheme as long as you use only XPath expressions (don't use xpointer points and ranges); of course it works in DOM-parsing style, but also in SAX-parsing style if your XPath expressions don't have to look backwards have a look at what is supported here: http://reflex.gforge.inria.fr/tests-xinclude.html -- Cordialement, /// (. .) --------ooO--(_)--Ooo-------- | Philippe Poulard | ----------------------------- http://reflex.gforge.inria.fr/ Have the RefleX ! _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304929.html short answer (from the support team of Altova) : it might exist in a future version. On Thu, Oct 15, 2009 at 10:43 AM, Philippe Poulard <philippe.poulard@sophia.inria.fr> wrote: > Olivier Rossel a écrit : >> >> oh btw, if anyone has managed to activate the XInclude inlining >> mechanism of XmlSpy2009, please contact me privately. >> I am going mad with this tool!!!! >> >> Philippe, thank you again! > > not sure it is supported, the xpointer() scheme appears to be "retired": > http://www.w3.org/TR/ > >> >> On Thu, Oct 15, 2009 at 10:20 AM, Olivier Rossel >> <olivier.rossel@gmail.com> wrote: >>> >>> merci beaucoup :) >>> >>> >>> >>> On Thu, Oct 15, 2009 at 8:58 AM, Philippe Poulard >>> <philippe.poulard@sophia.inria.fr> wrote: >>>> >>>> Hi Olivier, >>>> >>>> Olivier Rossel a écrit : >>>>> >>>>> ------- >>>>> Short questions: >>>>> ------- >>>>> >>>>> 1: Can a XPointer point to a #text node? >>>> >>>> I think yes, with the xpointer() scheme >>>> >>>>> 2: Can I XInclude a #text node? >>>> >>>> yes ! >>>> >>>>> ------- >>>>> Long explanation: >>>>> ------- >>>>> >>>>> Currently I have such anXInclude: >>>>> >>>>> <root xmlns:xi="http://www.w3.org/2001/XInclude"> >>>>>       <xi:include href="alternate.xml" parse="xml" >>>>> xpointer="element(/1/1)"/> >>>> >>>> <xi:include href="alternate.xml" parse="xml" >>>> xpointer="xpointer(string(/insideItr))"/> >>>> >>>>> </root> >>>>> >>>>> with alternate.xml: >>>>> >>>>> <inside> >>>>>  <insideItr>waza</insideItr> >>>>> </inside> >>>>> >>>>> and i get this final result: >>>>> >>>>> <root xmlns:xi="http://www.w3.org/2001/XInclude"> >>>>>  <insideItr xml:base="alternate.xml">waza</insideItr> >>>>> </root> >>>>> >>>>> and i would like this result instead: >>>>> >>>>> <root xmlns:xi="http://www.w3.org/2001/XInclude"> >>>>>  waza >>>>> </root> >>>>> >>>>> _______________________________________________________________________ >>>>> >>>>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >>>>> to support XML implementation and development. To minimize >>>>> spam in the archives, you must subscribe before posting. >>>>> >>>>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >>>>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >>>>> subscribe: xml-dev-subscribe@lists.xml.org >>>>> List archive: http://lists.xml.org/archives/xml-dev/ >>>>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >>>>> >>>> >>>> -- >>>> Cordialement, >>>> >>>>             /// >>>>            (. .) >>>>  --------ooO--(_)--Ooo-------- >>>> |      Philippe Poulard       | >>>>  ----------------------------- >>>>  http://reflex.gforge.inria.fr/ >>>>      Have the RefleX ! >>>> >> >> _______________________________________________________________________ >> >> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >> to support XML implementation and development. To minimize >> spam in the archives, you must subscribe before posting. >> >> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >> subscribe: xml-dev-subscribe@lists.xml.org >> List archive: http://lists.xml.org/archives/xml-dev/ >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >> > > > -- > Cordialement, > >              /// >             (. .) >  --------ooO--(_)--Ooo-------- > |      Philippe Poulard       | >  ----------------------------- >  http://reflex.gforge.inria.fr/ >       Have the RefleX ! > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304928.html Olivier Rossel a écrit : > oh btw, if anyone has managed to activate the XInclude inlining > mechanism of XmlSpy2009, please contact me privately. > I am going mad with this tool!!!! > > Philippe, thank you again! not sure it is supported, the xpointer() scheme appears to be "retired": http://www.w3.org/TR/ > > On Thu, Oct 15, 2009 at 10:20 AM, Olivier Rossel > <olivier.rossel@gmail.com> wrote: >> merci beaucoup :) >> >> >> >> On Thu, Oct 15, 2009 at 8:58 AM, Philippe Poulard >> <philippe.poulard@sophia.inria.fr> wrote: >>> Hi Olivier, >>> >>> Olivier Rossel a écrit : >>>> ------- >>>> Short questions: >>>> ------- >>>> >>>> 1: Can a XPointer point to a #text node? >>> I think yes, with the xpointer() scheme >>> >>>> 2: Can I XInclude a #text node? >>> yes ! >>> >>>> ------- >>>> Long explanation: >>>> ------- >>>> >>>> Currently I have such anXInclude: >>>> >>>> <root xmlns:xi="http://www.w3.org/2001/XInclude"> >>>> <xi:include href="alternate.xml" parse="xml" >>>> xpointer="element(/1/1)"/> >>> <xi:include href="alternate.xml" parse="xml" >>> xpointer="xpointer(string(/insideItr))"/> >>> >>>> </root> >>>> >>>> with alternate.xml: >>>> >>>> <inside> >>>> <insideItr>waza</insideItr> >>>> </inside> >>>> >>>> and i get this final result: >>>> >>>> <root xmlns:xi="http://www.w3.org/2001/XInclude"> >>>> <insideItr xml:base="alternate.xml">waza</insideItr> >>>> </root> >>>> >>>> and i would like this result instead: >>>> >>>> <root xmlns:xi="http://www.w3.org/2001/XInclude"> >>>> waza >>>> </root> >>>> >>>> _______________________________________________________________________ >>>> >>>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >>>> to support XML implementation and development. To minimize >>>> spam in the archives, you must subscribe before posting. >>>> >>>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >>>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >>>> subscribe: xml-dev-subscribe@lists.xml.org >>>> List archive: http://lists.xml.org/archives/xml-dev/ >>>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >>>> >>> >>> -- >>> Cordialement, >>> >>> /// >>> (. .) >>> --------ooO--(_)--Ooo-------- >>> | Philippe Poulard | >>> ----------------------------- >>> http://reflex.gforge.inria.fr/ >>> Have the RefleX ! >>> > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > -- Cordialement, /// (. .) --------ooO--(_)--Ooo-------- | Philippe Poulard | ----------------------------- http://reflex.gforge.inria.fr/ Have the RefleX ! _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304927.html oh btw, if anyone has managed to activate the XInclude inlining mechanism of XmlSpy2009, please contact me privately. I am going mad with this tool!!!! Philippe, thank you again! On Thu, Oct 15, 2009 at 10:20 AM, Olivier Rossel <olivier.rossel@gmail.com> wrote: > merci beaucoup :) > > > > On Thu, Oct 15, 2009 at 8:58 AM, Philippe Poulard > <philippe.poulard@sophia.inria.fr> wrote: >> Hi Olivier, >> >> Olivier Rossel a écrit : >>> >>> ------- >>> Short questions: >>> ------- >>> >>> 1: Can a XPointer point to a #text node? >> >> I think yes, with the xpointer() scheme >> >>> 2: Can I XInclude a #text node? >> >> yes ! >> >>> ------- >>> Long explanation: >>> ------- >>> >>> Currently I have such anXInclude: >>> >>> <root xmlns:xi="http://www.w3.org/2001/XInclude"> >>>        <xi:include href="alternate.xml" parse="xml" >>> xpointer="element(/1/1)"/> >> >> <xi:include href="alternate.xml" parse="xml" >> xpointer="xpointer(string(/insideItr))"/> >> >>> </root> >>> >>> with alternate.xml: >>> >>> <inside> >>>  <insideItr>waza</insideItr> >>> </inside> >>> >>> and i get this final result: >>> >>> <root xmlns:xi="http://www.w3.org/2001/XInclude"> >>>  <insideItr xml:base="alternate.xml">waza</insideItr> >>> </root> >>> >>> and i would like this result instead: >>> >>> <root xmlns:xi="http://www.w3.org/2001/XInclude"> >>>  waza >>> </root> >>> >>> _______________________________________________________________________ >>> >>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >>> to support XML implementation and development. To minimize >>> spam in the archives, you must subscribe before posting. >>> >>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >>> subscribe: xml-dev-subscribe@lists.xml.org >>> List archive: http://lists.xml.org/archives/xml-dev/ >>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >>> >> >> >> -- >> Cordialement, >> >>              /// >>             (. .) >>  --------ooO--(_)--Ooo-------- >> |      Philippe Poulard       | >>  ----------------------------- >>  http://reflex.gforge.inria.fr/ >>       Have the RefleX ! >> > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304926.html merci beaucoup :) On Thu, Oct 15, 2009 at 8:58 AM, Philippe Poulard <philippe.poulard@sophia.inria.fr> wrote: > Hi Olivier, > > Olivier Rossel a écrit : >> >> ------- >> Short questions: >> ------- >> >> 1: Can a XPointer point to a #text node? > > I think yes, with the xpointer() scheme > >> 2: Can I XInclude a #text node? > > yes ! > >> ------- >> Long explanation: >> ------- >> >> Currently I have such anXInclude: >> >> <root xmlns:xi="http://www.w3.org/2001/XInclude"> >>        <xi:include href="alternate.xml" parse="xml" >> xpointer="element(/1/1)"/> > > <xi:include href="alternate.xml" parse="xml" > xpointer="xpointer(string(/insideItr))"/> > >> </root> >> >> with alternate.xml: >> >> <inside> >>  <insideItr>waza</insideItr> >> </inside> >> >> and i get this final result: >> >> <root xmlns:xi="http://www.w3.org/2001/XInclude"> >>  <insideItr xml:base="alternate.xml">waza</insideItr> >> </root> >> >> and i would like this result instead: >> >> <root xmlns:xi="http://www.w3.org/2001/XInclude"> >>  waza >> </root> >> >> _______________________________________________________________________ >> >> XML-DEV is a publicly archived, unmoderated list hosted by OASIS >> to support XML implementation and development. To minimize >> spam in the archives, you must subscribe before posting. >> >> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >> subscribe: xml-dev-subscribe@lists.xml.org >> List archive: http://lists.xml.org/archives/xml-dev/ >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >> > > > -- > Cordialement, > >              /// >             (. .) >  --------ooO--(_)--Ooo-------- > |      Philippe Poulard       | >  ----------------------------- >  http://reflex.gforge.inria.fr/ >       Have the RefleX ! > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304925.html Hi Olivier, Olivier Rossel a écrit : > ------- > Short questions: > ------- > > 1: Can a XPointer point to a #text node? I think yes, with the xpointer() scheme > 2: Can I XInclude a #text node? yes ! > ------- > Long explanation: > ------- > > Currently I have such anXInclude: > > <root xmlns:xi="http://www.w3.org/2001/XInclude"> > <xi:include href="alternate.xml" parse="xml" xpointer="element(/1/1)"/> <xi:include href="alternate.xml" parse="xml" xpointer="xpointer(string(/insideItr))"/> > </root> > > with alternate.xml: > > <inside> > <insideItr>waza</insideItr> > </inside> > > and i get this final result: > > <root xmlns:xi="http://www.w3.org/2001/XInclude"> > <insideItr xml:base="alternate.xml">waza</insideItr> > </root> > > and i would like this result instead: > > <root xmlns:xi="http://www.w3.org/2001/XInclude"> > waza > </root> > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > -- Cordialement, /// (. .) --------ooO--(_)--Ooo-------- | Philippe Poulard | ----------------------------- http://reflex.gforge.inria.fr/ Have the RefleX ! _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304923.html ------- Short questions: ------- 1: Can a XPointer point to a #text node? 2: Can I XInclude a #text node? ------- Long explanation: ------- Currently I have such anXInclude: <root xmlns:xi="http://www.w3.org/2001/XInclude"> <xi:include href="alternate.xml" parse="xml" xpointer="element(/1/1)"/> </root> with alternate.xml: <inside> <insideItr>waza</insideItr> </inside> and i get this final result: <root xmlns:xi="http://www.w3.org/2001/XInclude"> <insideItr xml:base="alternate.xml">waza</insideItr> </root> and i would like this result instead: <root xmlns:xi="http://www.w3.org/2001/XInclude"> waza </root> _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304909.html It would really help if you show a concrete problem that you are trying to solve. (Is there a problem?) I am only guessing that you, like many find it painful to work with DOM directly and want an abstraction layer. In conclusion, I think all you need is a js library like jQuery. While I love the declarative style of XSL and I use it a lot, I am also aware of it's limitations. In this case, I don't how see using XSL would be beneficial vs the complication it brings, the amount of js code you'd need to transfer to make run on the client etc... Lech _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304908.html Dear Michael, Liam and Bjoern, Thank you all. I appreciate your explanation. Regards, Yang Quoting Michael Kay <mike@saxonica.com>: > One other point: you need to know what the root element type is. Technically > this is not part of the document type definition (=DTD), rather it is part > of the document type declaration. The two are often (understandably) > confused. > > Regards, > > Michael Kay > http://www.saxonica.com/ > http://twitter.com/michaelhkay > > >> -----Original Message----- >> From: Liam Quin [mailto:liam@w3.org] >> Sent: 13 October 2009 01:04 >> To: ycao5@scs.carleton.ca >> Cc: xml-dev@lists.xml.org >> Subject: Re: [xml-dev] Does DTD allow deriving all possible >> paths in an XMLdocument? >> >> On Mon, Oct 12, 2009 at 07:10:26PM -0400, ycao5@scs.carleton.ca wrote: >> > I have one question about XML DTD. In a paper, the authors say >> > that DTD allows deriving all possible paths from the root to the >> > leaves appearing in related XML documents. Does this statement >> > correct? Based on my knowledge, DTD may not contain all possible >> > elements in an XML document. I would like to get your >> opinion. Thanks. >> >> If you say that the XML document must be dtd-valid, then all >> elements in the document must be listed (and defined) in the DTD. >> >> A ontent model like >> <!ELEMENT mayhem ANY> >> means that "mayhem" elements may contain any elements at all >> as children (as well as text), but for the document to be >> valid the elemets must still be declared. >> >> However, it is not possible to precompute all paths to leaves, because >> (1) mayhem could have any elements as children >> (2) a recursive content content model does not generate a finite >> grammar - there's an unbounded set of possible valid input >> documents. >> >> e.g. <!ELEMENT doll (doll?)> >> allows >> <doll><doll><doll /></doll></doll> >> to any depth. >> >> These two points, ANY and cursion, are also rtue for SGML. >> >> Liam >> >> >> -- >> Liam Quin, W3C XML Activity Lead, >> http://www.w3.org/People/Quin/ http://www.holoweb.net/~liam/ >> * http://www.fromoldbooks.org/ >> >> ______________________________________________________________ >> _________ >> >> XML-DEV is a publicly archived, unmoderated list hosted by >> OASIS to support XML implementation and development. To >> minimize spam in the archives, you must subscribe before posting. >> >> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org >> subscribe: xml-dev-subscribe@lists.xml.org List archive: >> http://lists.xml.org/archives/xml-dev/ >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >> > > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304892.html One other point: you need to know what the root element type is. Technically this is not part of the document type definition (=DTD), rather it is part of the document type declaration. The two are often (understandably) confused. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay > -----Original Message----- > From: Liam Quin [mailto:liam@w3.org] > Sent: 13 October 2009 01:04 > To: ycao5@scs.carleton.ca > Cc: xml-dev@lists.xml.org > Subject: Re: [xml-dev] Does DTD allow deriving all possible > paths in an XMLdocument? > > On Mon, Oct 12, 2009 at 07:10:26PM -0400, ycao5@scs.carleton.ca wrote: > > I have one question about XML DTD. In a paper, the authors say > > that DTD allows deriving all possible paths from the root to the > > leaves appearing in related XML documents. Does this statement > > correct? Based on my knowledge, DTD may not contain all possible > > elements in an XML document. I would like to get your > opinion. Thanks. > > If you say that the XML document must be dtd-valid, then all > elements in the document must be listed (and defined) in the DTD. > > A ontent model like > <!ELEMENT mayhem ANY> > means that "mayhem" elements may contain any elements at all > as children (as well as text), but for the document to be > valid the elemets must still be declared. > > However, it is not possible to precompute all paths to leaves, because > (1) mayhem could have any elements as children > (2) a recursive content content model does not generate a finite > grammar - there's an unbounded set of possible valid input > documents. > > e.g. <!ELEMENT doll (doll?)> > allows > <doll><doll><doll /></doll></doll> > to any depth. > > These two points, ANY and cursion, are also rtue for SGML. > > Liam > > > -- > Liam Quin, W3C XML Activity Lead, > http://www.w3.org/People/Quin/ http://www.holoweb.net/~liam/ > * http://www.fromoldbooks.org/ > > ______________________________________________________________ > _________ > > XML-DEV is a publicly archived, unmoderated list hosted by > OASIS to support XML implementation and development. To > minimize spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org List archive: > http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304882.html On Mon, Oct 12, 2009 at 07:10:26PM -0400, ycao5@scs.carleton.ca wrote: > I have one question about XML DTD. In a paper, the authors say that > DTD allows deriving all possible paths from the root to the leaves > appearing in related XML documents. Does this statement correct? Based on > my knowledge, DTD may not contain all possible elements in an XML > document. I would like to get your opinion. Thanks. If you say that the XML document must be dtd-valid, then all elements in the document must be listed (and defined) in the DTD. A ontent model like <!ELEMENT mayhem ANY> means that "mayhem" elements may contain any elements at all as children (as well as text), but for the document to be valid the elemets must still be declared. However, it is not possible to precompute all paths to leaves, because (1) mayhem could have any elements as children (2) a recursive content content model does not generate a finite grammar - there's an unbounded set of possible valid input documents. e.g. <!ELEMENT doll (doll?)> allows <doll><doll><doll /></doll></doll> to any depth. These two points, ANY and cursion, are also rtue for SGML. Liam -- Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/ http://www.holoweb.net/~liam/ * http://www.fromoldbooks.org/ _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304870.html * ycao5@scs.carleton.ca wrote: > I have one question about XML DTD. In a paper, the authors say >that DTD allows deriving all possible paths from the root to the >leaves appearing in related XML documents. Does this statement >correct? Based on my knowledge, DTD may not contain all possible >elements in an XML document. I would like to get your opinion. Thanks. The XML specification in effect gives a definition for all possible paths in well-formed documents. A document type definition specifies a subset of that set in valid documents with respect to the document type definition. In other words, it allows you discriminate between paths that may occur in valid documents and paths that must not. In that the statement is correct. You are also correct that a document type definition may not specify all elements in some document, such documents are not valid however. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304868.html Hello everyone, I have one question about XML DTD. In a paper, the authors say that DTD allows deriving all possible paths from the root to the leaves appearing in related XML documents. Does this statement correct? Based on my knowledge, DTD may not contain all possible elements in an XML document. I would like to get your opinion. Thanks. _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304867.html For those working with XML vocabularies incorporating code lists, identifier lists or other controlled vocabularies, there is a hands-on training class on working with related OASIS technologies. Accommodating instance-level metadata, list-level metadata and value-level metadata is important when dealing with code lists, and schema-only approaches with enumerations do not meet many of the business requirements for maintenance, subsetting and extending code lists to meet real-world requirements. The OASIS genericode format and OASIS context/value association format do address these issues. Two deliveries on different continents are coming up this month, and the arrangements for Copenhagen as the first of the two are now set: http://www.CraneSoftwrights.com/index.html#Crane200910CPH The location for the hands-on code list training October 20, 2009 (and hands-on UBL training October 21, 2009) has been finalized as: Room 023 Bredgade 40 1260 Copenhagen K Denmark The code list training materials have all been updated to the latest public review draft submission made to the OASIS TC Administration for posting. http://www.oasis-open.org/committees/document.php?document_id=34538 Registration is still open and there are seats remaining to be picked up. Please register as soon as possible to ensure your seat. Details will be posted next week on the same training in Washington DC the week following Copenhagen. Thanks! . . . . . . . . . . Ken -- Upcoming: hands-on code list, UBL, XSLT, XQuery and XSL-FO classes in Copenhagen Denmark and Washington DC USA, October/November 2009 Interested in other classes? http://www.CraneSoftwrights.com/x/i/ Crane Softwrights Ltd. http://www.CraneSoftwrights.com/x/ Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video Video lesson: http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18 Video overview: http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18 G. Ken Holman mailto:gkholman@CraneSoftwrights.com Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/x/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304673.html Hi, I am pleased to announce that a new major version of oXygen XML editor is available from our website http://www.oxygenxml.com Version 11 of <oXygen/> XML Editor comes with exciting new features covering both XML development and XML authoring like: * XProc support * integrated documentation for XSLT stylesheets * a new XQuery debugger (for the Oracle Berkeley DB XML database) * MathML rendering and editing support * a smarter Author mode for an improved visual editing experience * DITA 1.2 features The support for very large documents was improved to handle documents in the 200MB range in the editor and 10GB in the large files viewer. The SVN support was upgraded with new features and a number of processors and frameworks were updated to their latest versions, including Saxon 9 and jing-trang. <oXygen/> 11 contains also an experimental integration with the EMC Documentum Content Management System. For the complete list of new additions in version 11 and details please see http://www.oxygenxml.com/index.html#new-version Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304672.html Thomas Lord wrote: > I am looking for a piece of software that I've > come to suspect doesn't exist - but I thought > I'd ask here as one way to double check. JS+XSLT+MVC brings Freja in mind: "Freja (Framework for Restful Javascript Applications) is not yet another Ajax library. It is an Open-Source, MVC, High Level Ajax based Javascript Framework that lets you use your favorite javascript library if you wish. It actually plays well with other javascript toolkits and libraries (prototype, scriptaculous, dojo, etc..)." Freja implements the MVC pattern but I'm not sure on how much it will help you do incremental XSLT processing on the DOM - shouldn't be a big issue by itself though. The Freja home page seems to be down at the moment... should be easy to find examples like [1]. [1] http://formassembly.com/blog/the-freja-framework/ Hth, Manos _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304645.html Thomas, The technology you are looking for is the core technology of our XML editor Xopus. We have built an XML DOM implementation with a live XSL transformation to HTML. All written in Javascript and XSLT. Calling DOM methods will update the XML, we will validate changed XML against an XSD for good measure and rollback the transaction when it is invalid, then the XSLT will be reapplied automatically and the HTML will be updated accordingly. See http://xopus.com/demos.html for a demo. This does meet all your technical requirements, but the technology is not free. The editor is available under a commercial license, but we're willing to discuss licensing part of the technology as well. Best regards, Laurens van den Oever CEO, Xopus BV laurens at xopus.com http://xopus.com +31 70 4452345 Waldorpstraat 17G 2521 CA Den Haag The Netherlands KvK 27301795 2009/10/8 Thomas Lord <lord@emf.net> > I am looking for a piece of software that I've > come to suspect doesn't exist - but I thought > I'd ask here as one way to double check. > > We are used to the idea of browsers receiving > XML, retrieving a linked XSLT program, and applying > that program to produce an HTML DOM for display. > > I am wishing for taking that one step further. > I would like a client-side XSLT implementation > that does that transform, but that also keeps around > the XML. I would like Javascript programs to be > able to modify the XML DOM objects and to have those > changes *incrementally* reflected in updates to > the HTML DOM. > > I know that for arbitrary XSLT, such incremental > transforms can not always be fast. For example, > it is trivial to write an XSLT program such that a > single character change to a text datum in the XML > causes the HTML to have to be completely regenerated > from scratch. > > I do hope for a solution where it is easy to write > a wide range of XSLT programs that *can* be updated > fast, incrementally. That is to say: I want good > performance in the easy cases and don't care so much > how the hard cases are handled. > > I would prefer XSLT but I suppose it is not essential. > Something similar but non-standard is OK, if that's all > there is. > > Why do I want this? Well: > > I would like to build a system that roughly follows > a "model-view-controller" pattern. The XML will > serve as model. The HTML and some event handling hooks > will serve as view. The main logic of an application > are the commands (in Javascript) that the view can > trigger and which operate by having side effects on > the XML (the model) - that "command system" of the > application is the controller. > > Is there such a piece of software around (that is > licensed as free software)? My impression is that > there is not - which I find somewhat surprising. > > Finally, one person I mentioned this to admonished me > that I was proposing to use XSLT and Javascript in ways > they were never intended for and were ill suited for. > I could not get a clear sense from him of *why* he > thought so, but that is what he said. Is he right? > > Thanks, > -t > > > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > >]]> http://www.altova.com/list/xml-dev/200910/msg1000304639.html It's probably not the environment Thomas is looking for, but I believe that InfoPath works this way. It uses XSLT (along with some extension attributes) to define a round-trip mapping between stylesheet and source tree. Those source-result bindings allow the processor to redraw part of the result without having to run the whole transformation over again. Chapter 10 (which I wrote) of Office 2003 XML[1] is basically a revserse-engineering of InfoPath's XSLT internals. I don't recall if I covered this optimization in the book, but I seem to recall reading about it. Here's a quote I found just now: "To avoid running the entire XSLT transformation every time the end user enters data in a view or clicks a formatting control for rich text, algorithms are used to determine which portion of the view needs to be refreshed. Then only the relevant portion of the XSLT stylesheet is applied to the DOM, and the affected portion of the view is refreshed."[2] Evan Lenz http://lenzconsulting.com [1] http://books.google.com/books?id=xYEyK_7TWP8C&pg=PA426 [2] http://msdn.microsoft.com/en-us/library/bb608310(office.11).aspx Michael Kay wrote: >> I want a second DOM around - an XML object. The HTML >> DOM for the page is related to the XML object either >> literally by an XSLT script or by something similar. >> When I change the *XML DOM* - I want the HTML transformed DOM >> to be incrementally updated. >> >> > ... > >> I am looking for a way so that if the Javascript program >> modifies the XML - say by adding an additional book - that >> the HTML DOM is automagically updated, say by inserting a new >> "li" element in the appropriate place. >> >> > > Incremental transformation - only changing those parts of the output that > are affected by a change to the input - was one of the potential benefits > touted when XSLT was designed, and was said to be possible because of the > declarative nature of XSLT. In practice, it hasn't been delivered. I'm sure > it can be done in principle, as demonstrated by the "back-mapping" done by > debugging tools, which link elements in the output to the elements in the > input from which they were derived. But there's not much investment going > into client-side XSLT, which might have something to do with the fact that > it's rather hard to make a business case for such investment. > > Regards, > > Michael Kay > http://www.saxonica.com/ > http://twitter.com/michaelhkay > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304616.html > > I want a second DOM around - an XML object. The HTML > DOM for the page is related to the XML object either > literally by an XSLT script or by something similar. > When I change the *XML DOM* - I want the HTML transformed DOM > to be incrementally updated. > ... > > I am looking for a way so that if the Javascript program > modifies the XML - say by adding an additional book - that > the HTML DOM is automagically updated, say by inserting a new > "li" element in the appropriate place. > Incremental transformation - only changing those parts of the output that are affected by a change to the input - was one of the potential benefits touted when XSLT was designed, and was said to be possible because of the declarative nature of XSLT. In practice, it hasn't been delivered. I'm sure it can be done in principle, as demonstrated by the "back-mapping" done by debugging tools, which link elements in the output to the elements in the input from which they were derived. But there's not much investment going into client-side XSLT, which might have something to do with the fact that it's rather hard to make a business case for such investment. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304611.html On Thu, 2009-10-08 at 13:53 -0700, w3c@drrw.info wrote: > Thomas, > Once the content is loaded into the DOM in the browser content it is > fully accessible by the Javascript. Yes, of course. I want to have javascript programs update the display with changes to the HTML DOM of the page. However, I don't want the javascript programs to touch that DOM directly but rather through a library. I want a second DOM around - an XML object. The HTML DOM for the page is related to the XML object either literally by an XSLT script or by something similar. When I change the *XML DOM* - I want the HTML transformed DOM to be incrementally updated. For example, suppose my Javascript program has requested some resource and got back XML like: <books> <title>Gnu Emacs Manual</title> <title>Mathematial Logic and Programming Languages</title> <title>Smalltalk 80: The Language and its Implementation</title> </books> and the XSLT program transforms that into any number of possible presentations, such as: <ul> <li>Gnu Emacs Manual</li> ...etc... </ul> I am looking for a way so that if the Javascript program modifies the XML - say by adding an additional book - that the HTML DOM is automagically updated, say by inserting a new "li" element in the appropriate place. > But it sounds like you want something that reacts to incoming events > too - again Javascript can send and receive SOAP messages / or REST / > for example - and update accordingly. Yes, I know all of that. I'm very narrowly interested in a "missing piece" which is this incrementally updatable XML->HTTP transform. > This is all done already - initial xslt runs loads xml, html and > javascript into browser - its called AJAX! It's not. You've misunderstood. I'm dumb as a post, I'm sure, but I'm not *that* stupid :-) -t > > Enjoy, DW > > > -------- Original Message -------- > Subject: [xml-dev] help request: incremental XSLT(-ish?) in > javascript > From: Thomas Lord <lord@emf.net> > Date: Thu, October 08, 2009 2:33 pm > To: xml-dev@lists.xml.org > > I am looking for a piece of software that I've > come to suspect doesn't exist - but I thought > I'd ask here as one way to double check. > > We are used to the idea of browsers receiving > XML, retrieving a linked XSLT program, and applying > that program to produce an HTML DOM for display. > > I am wishing for taking that one step further. > I would like a client-side XSLT implementation > that does that transform, but that also keeps around > the XML. I would like Javascript programs to be > able to modify the XML DOM objects and to have those > changes *incrementally* reflected in updates to > the HTML DOM. > > I know that for arbitrary XSLT, such incremental > transforms can not always be fast. For example, > it is trivial to write an XSLT program such that a > single character change to a text datum in the XML > causes the HTML to have to be completely regenerated > from scratch. > > I do hope for a solution where it is easy to write > a wide range of XSLT programs that *can* be updated > fast, incrementally. That is to say: I want good > performance in the easy cases and don't care so much > how the hard cases are handled. > > I would prefer XSLT but I suppose it is not essential. > Something similar but non-standard is OK, if that's all > there is. > > Why do I want this? Well: > > I would like to build a system that roughly follows > a "model-view-controller" pattern. The XML will > serve as model. The HTML and some event handling hooks > will serve as view. The main logic of an application > are the commands (in Javascript) that the view can > trigger and which operate by having side effects on > the XML (the model) - that "command system" of the > application is the controller. > > Is there such a piece of software around (that is > licensed as free software)? My impression is that > there is not - which I find somewhat surprising. > > Finally, one person I mentioned this to admonished me > that I was proposing to use XSLT and Javascript in ways > they were never intended for and were ill suited for. > I could not get a clear sense from him of *why* he > thought so, but that is what he said. Is he right? > > Thanks, > -t > > > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by > OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: > http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: > http://www.oasis-open.org/maillists/guidelines.php > > > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304610.html On Thu, Oct 8, 2009 at 8:45 PM, Thomas Lord <lord@emf.net> wrote: > On Thu, 2009-10-08 at 20:39 +0200, James Fuller wrote: >> xcruciate.co.uk > > Thanks.  No, that doesn''t look like what I''m after > unless I''m missing something. > > It''s critical to my requirements that this incremental > transform engine run in Javascript, in browsers. missed that requirement completely ... xcruciate is all serverside I have not heard of anything of what u want on the clientside gl, Jim Fuller _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304607.html On Thu, Oct 8, 2009 at 8:45 PM, Thomas Lord <lord@emf.net> wrote: > On Thu, 2009-10-08 at 20:39 +0200, James Fuller wrote: >> xcruciate.co.uk > > Thanks.  No, that doesn't look like what I'm after > unless I'm missing something. > > It's critical to my requirements that this incremental > transform engine run in Javascript, in browsers. missed that requirement completely ... xcruciate is all serverside I have not heard of anything of what u want on the clientside gl, Jim Fuller _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304604.html On Thu, 2009-10-08 at 20:39 +0200, James Fuller wrote: > xcruciate.co.uk Thanks. No, that doesn't look like what I'm after unless I'm missing something. It's critical to my requirements that this incremental transform engine run in Javascript, in browsers. Also, I don't see any incremental updates to transforms in xcruciate. (At least: if they are there, they don't brag prominently about them which you'd think they would and should.) -t _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304601.html u might find the emerging xcruciate server something that addresses some of your requirements xcruciate.co.uk J On Thu, Oct 8, 2009 at 8:33 PM, Thomas Lord <lord@emf.net> wrote: > I am looking for a piece of software that I've > come to suspect doesn't exist - but I thought > I'd ask here as one way to double check. > > We are used to the idea of browsers receiving > XML, retrieving a linked XSLT program, and applying > that program to produce an HTML DOM for display. > > I am wishing for taking that one step further. > I would like a client-side XSLT implementation > that does that transform, but that also keeps around > the XML.   I would like Javascript programs to be > able to modify the XML DOM objects and to have those > changes *incrementally* reflected in updates to > the HTML DOM. > > I know that for arbitrary XSLT, such incremental > transforms can not always be fast.   For example, > it is trivial to write an XSLT program such that a > single character change to a text datum in the XML > causes the HTML to have to be completely regenerated > from scratch. > > I do hope for a solution where it is easy to write > a wide range of XSLT programs that *can* be updated > fast, incrementally.   That is to say: I want good > performance in the easy cases and don't care so much > how the hard cases are handled. > > I would prefer XSLT but I suppose it is not essential. > Something similar but non-standard is OK, if that's all > there is. > > Why do I want this?  Well: > > I would like to build a system that roughly follows > a "model-view-controller" pattern.   The XML will > serve as model.   The HTML and some event handling hooks > will serve as view.  The main logic of an application > are the commands (in Javascript) that the view can > trigger and which operate by having side effects on > the XML (the model) - that "command system" of the > application is the controller. > > Is there such a piece of software around (that is > licensed as free software)?  My impression is that > there is not - which I find somewhat surprising. > > Finally, one person I mentioned this to admonished me > that I was proposing to use XSLT and Javascript in ways > they were never intended for and were ill suited for. > I could not get a clear sense from him of *why* he > thought so, but that is what he said.  Is he right? > > Thanks, > -t > > > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304600.html I am looking for a piece of software that I've come to suspect doesn't exist - but I thought I'd ask here as one way to double check. We are used to the idea of browsers receiving XML, retrieving a linked XSLT program, and applying that program to produce an HTML DOM for display. I am wishing for taking that one step further. I would like a client-side XSLT implementation that does that transform, but that also keeps around the XML. I would like Javascript programs to be able to modify the XML DOM objects and to have those changes *incrementally* reflected in updates to the HTML DOM. I know that for arbitrary XSLT, such incremental transforms can not always be fast. For example, it is trivial to write an XSLT program such that a single character change to a text datum in the XML causes the HTML to have to be completely regenerated from scratch. I do hope for a solution where it is easy to write a wide range of XSLT programs that *can* be updated fast, incrementally. That is to say: I want good performance in the easy cases and don't care so much how the hard cases are handled. I would prefer XSLT but I suppose it is not essential. Something similar but non-standard is OK, if that's all there is. Why do I want this? Well: I would like to build a system that roughly follows a "model-view-controller" pattern. The XML will serve as model. The HTML and some event handling hooks will serve as view. The main logic of an application are the commands (in Javascript) that the view can trigger and which operate by having side effects on the XML (the model) - that "command system" of the application is the controller. Is there such a piece of software around (that is licensed as free software)? My impression is that there is not - which I find somewhat surprising. Finally, one person I mentioned this to admonished me that I was proposing to use XSLT and Javascript in ways they were never intended for and were ill suited for. I could not get a clear sense from him of *why* he thought so, but that is what he said. Is he right? Thanks, -t _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304599.html -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Brickley writes: > Although not as high-profile as a REC-track group, there is nothing to > stop a group of like-minded W3C members single-handedly chartering an > Incubator Group (XG, see http://www.w3.org/2005/Incubator/ ) to try to > progress the XHTML efforts. Perhaps - in part - by defining a recovery > model for ill-formed XML markup? The market will decide, but my take on what the XHTML users out there like about XHTML _includes_ the strict error checking discipline it imposes. . . ht - -- Henry S. Thompson, School of Informatics, University of Edinburgh Half-time member of W3C Team 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFKUzxVkjnJixAXWBoRAseoAJ4nbyEvju6tcR5t1j2kNb+aV0djXQCePDck K3hoSmCVIM8kWGHzonlYeHU= =7seS -----END PGP SIGNATURE----- _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304591.html rjelliffe@allette.com.au a écrit : >> could you elaborate on that relax NG + schematron? >> i can understand that chaining relax validation and schematron >> processing is definitely possible. >> >> but as far as i understand, they are no integration effort between them. IMHO, Schematron is not intended to be integrated; even if you embed it in RelaxNG (as mentioned below by Rick), the embedded part of Schematron will be ignored from the host language (each will ignore the other). For example, consider an XML editor within which the user is invited to insert a new element under a <purchase-order>; a schema processor will be able to propose the authorized elements, say <item> and <free-item>, as indicated by a RelaxNG schema; unfortunately, some additional constraints are not expressible with RelaxNG, say "a <free-item> element is allowed only if the total amount of the order is more than 500€", so they are expressed with Schematron; then the user select <free-item> since it is proposed by RelaxNG, but after insertion it will have a warning from Schematron: "you are not allowed to insert this element because..." The Active Schema Language (ASL) figures out elegantly this kind of issues by computing dynamically content models instead of serving them statically. Concretely, it can compute the content model mentioned above exactly as it is expressed: "a <purchase-order> is a sequence of <item>s, and if the total amount of the order is more than 500€, <free-item> is part of the sequence". So simple, so natural. ASL: http://ns.inria.fr/active-tags/active-schema/active-schema.html The engine is available here: http://reflex.gforge.inria.fr/ You can run various examples here: http://reflex.gforge.inria.fr/tutorial-schemas.html It was the topic of my talk at Balisage last year: "Properties of schema mashups: dynamicity, semantic, mixins, hyperschemas" http://www.balisage.net/Proceedings/vol1/html/Poulard01/BalisageVol1-Poulard01.html The slides: http://hal.inria.fr/docs/00/32/26/61/ANNEX/Bal2008poul061003.pdf > > Eddie Robertsson''s software to embed Schematron rules in RELAX NG has been > around since about 2001. > > Also both Schematron and RELAX NG are part of ISO DSDL: one > long-time-coming part of DSDL is a pipelining execution framework, with > XProc the candidate. The challenge I see with DSDL is not so much to > integrate RELAX NG and Schematron (why dilute one?) as to integrate the > other parts of DSDL with them. > > Cheers > Rick Jelliffe > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > -- Cordialement, /// (. .) --------ooO--(_)--Ooo-------- | Philippe Poulard | ----------------------------- http://reflex.gforge.inria.fr/ Have the RefleX ! _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304588.html rjelliffe@allette.com.au a écrit : >> could you elaborate on that relax NG + schematron? >> i can understand that chaining relax validation and schematron >> processing is definitely possible. >> >> but as far as i understand, they are no integration effort between them. IMHO, Schematron is not intended to be integrated; even if you embed it in RelaxNG (as mentioned below by Rick), the embedded part of Schematron will be ignored from the host language (each will ignore the other). For example, consider an XML editor within which the user is invited to insert a new element under a <purchase-order>; a schema processor will be able to propose the authorized elements, say <item> and <free-item>, as indicated by a RelaxNG schema; unfortunately, some additional constraints are not expressible with RelaxNG, say "a <free-item> element is allowed only if the total amount of the order is more than 500€", so they are expressed with Schematron; then the user select <free-item> since it is proposed by RelaxNG, but after insertion it will have a warning from Schematron: "you are not allowed to insert this element because..." The Active Schema Language (ASL) figures out elegantly this kind of issues by computing dynamically content models instead of serving them statically. Concretely, it can compute the content model mentioned above exactly as it is expressed: "a <purchase-order> is a sequence of <item>s, and if the total amount of the order is more than 500€, <free-item> is part of the sequence". So simple, so natural. ASL: http://ns.inria.fr/active-tags/active-schema/active-schema.html The engine is available here: http://reflex.gforge.inria.fr/ You can run various examples here: http://reflex.gforge.inria.fr/tutorial-schemas.html It was the topic of my talk at Balisage last year: "Properties of schema mashups: dynamicity, semantic, mixins, hyperschemas" http://www.balisage.net/Proceedings/vol1/html/Poulard01/BalisageVol1-Poulard01.html The slides: http://hal.inria.fr/docs/00/32/26/61/ANNEX/Bal2008poul061003.pdf > > Eddie Robertsson's software to embed Schematron rules in RELAX NG has been > around since about 2001. > > Also both Schematron and RELAX NG are part of ISO DSDL: one > long-time-coming part of DSDL is a pipelining execution framework, with > XProc the candidate. The challenge I see with DSDL is not so much to > integrate RELAX NG and Schematron (why dilute one?) as to integrate the > other parts of DSDL with them. > > Cheers > Rick Jelliffe > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > -- Cordialement, /// (. .) --------ooO--(_)--Ooo-------- | Philippe Poulard | ----------------------------- http://reflex.gforge.inria.fr/ Have the RefleX ! _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304583.html On Wed, Oct 7, 2009 at 6:28 PM, <w3c@drrw.info> wrote: > Olivier and Lech, > Thanks for your questions.  Been a while since I've posted to the xml-dev > list. Really good to hear from you. Sometimes it's wothwhile to stir the honet's nest alittle just to get an excellent response like yours. > I think it is important firstly to determine what the role and purpose of > each flavor of XML schema technology is, and hence what are the strengths > and where you would want to match appropriately to what your needs are. > So if I'm looking at XSD Schema, Relax NG, Schematron, and CAM for me its > pretty clear. You're absolutely right and having just re-read some of the publications on CAM last night, I can clearly see now that the CAM caters for a different use case. > Can CAM do things that XSD + Schematron cannot do? Most certainly - it > combines that into one technology. I'll certainly be looking more into that, it might fit into an ecosystem of what I'm doing really well. Lech _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304578.html > could you elaborate on that relax NG + schematron? > i can understand that chaining relax validation and schematron > processing is definitely possible. > > but as far as i understand, they are no integration effort between them. Eddie Robertsson's software to embed Schematron rules in RELAX NG has been around since about 2001. Also both Schematron and RELAX NG are part of ISO DSDL: one long-time-coming part of DSDL is a pipelining execution framework, with XProc the candidate. The challenge I see with DSDL is not so much to integrate RELAX NG and Schematron (why dilute one?) as to integrate the other parts of DSDL with them. Cheers Rick Jelliffe _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304519.html -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Brickley writes: > Although not as high-profile as a REC-track group, there is nothing to > stop a group of like-minded W3C members single-handedly chartering an > Incubator Group (XG, see http://www.w3.org/2005/Incubator/ ) to try to > progress the XHTML efforts. Perhaps - in part - by defining a recovery > model for ill-formed XML markup? The market will decide, but my take on what the XHTML users out there like about XHTML _includes_ the strict error checking discipline it imposes. . . ht - -- Henry S. Thompson, School of Informatics, University of Edinburgh Half-time member of W3C Team 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFKUzxVkjnJixAXWBoRAseoAJ4nbyEvju6tcR5t1j2kNb+aV0djXQCePDck K3hoSmCVIM8kWGHzonlYeHU= =7seS -----END PGP SIGNATURE----- _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304518.html On 10/7/2009 10:03 AM, Lech Rzedzicki wrote: > On Wed, Oct 7, 2009 at 1:53 PM, Olivier Rossel <olivier.rossel@gmail.com> wrote: >> i hope some people from CAM are around so we can discuss those points. > > I hope so too, I really would like to see the effort being pointed in > the right direction, such as extending one of the existing standards. > Despite my criticsm, there are some great ideas in there, such as > featuring code lists and separating business rules from defining XML > structure. Ideally I would really want to see the best of all schema > validation engines merged into one some time in the future. Agreed -- would love to see structure separated cleanly from business rules. Although I suppose you could organize an XSD in this way using references. _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php]]> http://www.altova.com/list/xml-dev/200910/msg1000304507.html Hi! This is the ezmlm program. I'm managing the xml-dev@lists.xml.org mailing list. I'm working for my owner, who can be reached at xml-dev-owner@lists.xml.org. Messages to you from the xml-dev mailing list seem to have been bouncing. I've attached a copy of the first bounce message I received. If this message bounces too, I will send you a probe. If the probe bounces, I will remove your address from the xml-dev mailing list, without further notice. I've kept a list of which messages from the xml-dev mailing list have bounced from your address. Copies of these messages may be in the archive. To retrieve a set of messages 123-145 (a maximum of 100 per request), send an empty message to: <xml-dev-get.123_145@lists.xml.org> To receive a subject and author list for the last 100 or so messages, send an empty message to: <xml-dev-index@lists.xml.org> Here are the message numbers: 52257 --- Enclosed is a copy of the bounce message I received. Return-Path: <> Received: (qmail 28777 invoked by uid 0); 25 Sep 2009 17:43:57 -0000 Received: from unknown (HELO ms01.oasis-open.org) (10.0.0.20) by mail.oasis-open.org with SMTP; 25 Sep 2009 17:43:57 -0000 Received: from Debian-exim by ms01.oasis-open.org with local id 1MrEpp-0001lU-Du for xml-dev-return-52257-xml-dev=abell.at@lists.xml.org; Fri, 25 Sep 2009 13:43:57 -0400 X-Failed-Recipients: xml-dev@abell.at Auto-Submitted: auto-generated From: Mail Delivery System <Mailer-Daemon@ms01.oasis-open.org> To: xml-dev-return-52257-xml-dev=abell.at@lists.xml.org Subject: Mail delivery failed: returning message to sender Message-Id: <E1MrEpp-0001lU-Du@ms01.oasis-open.org> Date: Fri, 25 Sep 2009 13:43:57 -0400 This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: xml-dev@abell.at SMTP error from remote mailer after end of data: host aspmx.l.google.com [209.85.212.91]: 552-5.7.0 Our system detected an illegal attachment on your message. Please 552-5.7.0 visit http://mail.google.com/support/bin/answer.py?answer=6590 to 552 5.7.0 review our attachment guidelines. 31si5694817vws.55 ------ This is a copy of the message, including all the headers. ------ ------ The body of the message is 1796439 characters long; only the first ------ 106496 or so are included here. Return-path: <xml-dev-return-52257-xml-dev=abell.at@lists.xml.org> Received: from [10.1.1.2] (helo=mail.oasis-open.org) by ms01.oasis-open.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) id 1MrDvd-0002Fd-Ag for xml-dev@abell.at; Fri, 25 Sep 2009 12:45:55 -0400 Received: (qmail 25613 invoked by uid 60909); 25 Sep 2009 16:43:34 -0000 Mailing-List: contact xml-dev-help@lists.xml.org; run by ezmlm Precedence: bulk List-Post: <mailto:xml-dev@lists.xml.org> List-Help: <mailto:xml-dev-help@lists.xml.org> List-Unsubscribe: <mailto:xml-dev-unsubscribe@lists.xml.org> List-Subscribe: <mailto:xml-dev-subscribe@lists.xml.org> Delivered-To: mailing list xml-dev@lists.xml.org Received: (qmail 25603 invoked by uid 0); 25 Sep 2009 16:43:33 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA3DFF.47C42C62" Date: Fri, 25 Sep 2009 12:43:14 -0400 Message-ID: <BF3D95EDD37088488ADB82FBBC5689CD06921796@CHN-EXMBXPR01.pfcuhq.penfed.ads> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: menuml -restaurant menu xml prototype app Thread-Index: Aco9/0a1RFkeXcD1Soqjqcxd6sEAEg== From: "Sharma, Dhruv" <Dhruv.Sharma@PenFed.org> To: <xml-dev@lists.xml.org> X-OriginalArrivalTime: 25 Sep 2009 16:43:16.0765 (UTC) FILETIME=[4803E4D0:01CA3DFF] Received-SPF: none X-Antivirus-Scanner: ClamAV at OASIS detected no problems X-Spam-Scanner: Skipped OASIS spam filter due to large message size. Subject: [xml-dev] menuml -restaurant menu xml prototype app ------_=_NextPart_001_01CA3DFF.47C42C62 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA3DFF.47C42C62" ------_=_NextPart_002_01CA3DFF.47C42C62 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This posting is about an XML menu application I designed for my parents restaurant years ago. The word document describes the design and the zip file contains the XML, and stylesheet to convert menu ml into PDF, HTML, and a JavaScript calculator. =20 The idea is that even small restaurants can cheaply use XML to manage their menus and be able to seamlessly convert them into multiple formats. =20 The design of menu ml is simple and could be used to develop a standard for restaurants to use help streamline operations. =20 The calculator which can be generated from the menu in XML is handy as if waiters, used Personal digital assistants (pdas), they can take orders without having to mess up orders via handwriting and also the price is added in automatically by the calculator leading to more accurate order processing and operations. =20 This should help anyone in need of XML for menu to do restaurant applications. The code (XML,xslt, dtd) is all in the zip and easy to follow and change. =20 There is not much on xml and restaurants so hopefully this will fill a niche or help others who wanted to do the same thing. =20 best Dhruv =20 =20 ------_=_NextPart_002_01CA3DFF.47C42C62 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.6000.16890" name=3DGENERATOR></HEAD> <BODY> <DIV><SPAN class=3D308303716-25092009><FONT face=3DArial=20 size=3D2>Hi,</FONT></SPAN></DIV> <DIV><SPAN class=3D308303716-25092009>&nbsp;&nbsp;&nbsp; <FONT = face=3DArial=20 size=3D2>This posting is about an XML menu application I designed for my = parents=20 restaurant years ago.</FONT></SPAN></DIV> <DIV><SPAN class=3D308303716-25092009>&nbsp;&nbsp;&nbsp; <FONT = face=3DArial=20 size=3D2>The word document describes the design and the zip file = contains the XML,=20 and stylesheet to convert menu ml into PDF, HTML, and a JavaScript=20 calculator.</FONT></SPAN></DIV> <DIV><SPAN class=3D308303716-25092009><FONT face=3DArial=20 size=3D2></FONT></SPAN>&nbsp;</DIV> <DIV><SPAN class=3D308303716-25092009>&nbsp;&nbsp;&nbsp; <FONT = face=3DArial=20 size=3D2>The idea is that even small restaurants can cheaply use XML to = manage=20 their menus and be able to seamlessly convert them into multiple=20 formats.</FONT></SPAN></DIV> <DIV><SPAN class=3D308303716-25092009><FONT face=3DArial=20 size=3D2></FONT></SPAN>&nbsp;</DIV> <DIV><SPAN class=3D308303716-25092009>&nbsp;&nbsp;&nbsp; <FONT = face=3DArial=20 size=3D2>The design of menu ml is simple and could be used to develop a = standard=20 for restaurants to use help streamline operations.</FONT></SPAN></DIV> <DIV><SPAN class=3D308303716-25092009><FONT face=3DArial=20 size=3D2></FONT></SPAN>&nbsp;</DIV> <DIV><SPAN class=3D308303716-25092009>&nbsp;&nbsp;&nbsp; <FONT = face=3DArial=20 size=3D2>The calculator which can be generated from the menu in XML is = handy as if=20 waiters, used Personal digital assistants (pdas), they can take orders = without=20 having to mess up orders via handwriting and also the price is added in=20 automatically by the calculator leading to more accurate order = processing and=20 operations.</FONT></SPAN></DIV> <DIV><SPAN class=3D308303716-25092009><FONT face=3DArial=20 size=3D2></FONT></SPAN>&nbsp;</DIV> <DIV><SPAN class=3D308303716-25092009>&nbsp;&nbsp;&nbsp; <FONT = face=3DArial=20 size=3D2>This should help anyone in need of XML for menu to do = restaurant=20 applications.&nbsp; The code (XML,xslt, dtd)&nbsp;is all in the zip and = easy to=20 follow and change.</FONT></SPAN></DIV> <DIV><SPAN class=3D308303716-25092009><FONT face=3DArial=20 size=3D2></FONT></SPAN>&nbsp;</DIV> <DIV><SPAN class=3D308303716-25092009>&nbsp;&nbsp;&nbsp; <FONT = face=3DArial=20 size=3D2>There is not much on xml and restaurants so hopefully this will = fill a=20 niche or help others who wanted to do the same = thing.</FONT></SPAN></DIV> <DIV><SPAN class=3D308303716-25092009><FONT face=3DArial=20 size=3D2></FONT></SPAN>&nbsp;</DIV> <DIV><SPAN class=3D308303716-25092009><FONT face=3DArial=20 size=3D2>best</FONT></SPAN></DIV> <DIV><SPAN class=3D308303716-25092009><FONT face=3DArial=20 size=3D2>Dhruv</FONT></SPAN></DIV> <DIV><SPAN class=3D308303716-25092009><FONT face=3DArial=20 size=3D2></FONT></SPAN>&nbsp;</DIV> <DIV><SPAN class=3D308303716-25092009><FONT face=3DArial=20 size=3D2></FONT></SPAN>&nbsp;</DIV></BODY></HTML> ------_=_NextPart_002_01CA3DFF.47C42C62-- ------_=_NextPart_001_01CA3DFF.47C42C62 Content-Type: application/x-zip-compressed; name="menuml files.zip" Content-Transfer-Encoding: base64 Content-Description: menuml files.zip Content-Disposition: attachment; filename="menuml files.zip" UEsDBBQAAAAIAMiILjuSpDAoCAEAACYCAAATAAAAbWVudW1sIGZpbGVzL2ExLmJhdI2QT2uEMBDF 74LfIdCzQe2tpYfFpexhlxZc6CUgY0yqNv9IdN1++yZae5At7Gkev3kzbxjaoOKJXEGASvoqr9Jq n2bEgTSCOVJ2oZ4tKMe1lXEUR44NqDjuyvJ9dz683JitO7Uw3IN9/s/ALGXuzyFFwrUh9diJhni1 bYiuJtMjvYW9XvHpG+01HSVTgwucfBzy1zefmlVpSHVkanOuF1B5sA72bmq+kgynOJt3OmYvgg1z O44eUA8XoGjzDBxo+Ih3BLntIwqcYX/GLEzD8dUtGnO9bkXafmIwQNtAjZfG4UJLCao5doqt/qX6 JXfEnZgaCxB0FDBo+5sqKG4HKe4YX8R66jL0A1BLAwQUAAAACADdai47zo2YApsDAABxMwAAFAAA AG1lbnVtbCBmaWxlcy9jYWZlLmZv7Vpdb5swFH1epP4HC+2VkDTd1kSlfdjUp22atE7aqwFDvBqb 2c5o9utnPgshWWoC7aS5T80FH+49Ptf3iOTq5iEm4BfiAjPqWvPpzAKI+izANHKtb3e39qV1c302 uQrZijMmgbqdilXIXGstZbJynDRNp+liynjkzJfLpfP960fnlvEYSqtcR+CWbaQdQyERtwXqBSJw nBBkJzBCJZIWCoghjzC1OY7W0rXOZ3FcxwgKd0Mek5LFio9mULKkiuRppDiQa9dazB5Da1TgX8zK hXnJFMbItbIbqmo4ihTf6jHB9pQyelexVAGnnQsMtTlFDxJRWeLvwHkoZBydiufs3fnqSkdYZQr5 rQL93Cgla6ZwcMeEhBL7ts9olqMeaEhYWkI+CGK3GKrwPcL8ez1YqfiyIcGRalxEAwv4jDCu0t5w RZh6rMrVDmGMyda1BKRCccJxWF4Q+LfKZ36e1C2W00Y3saepg3qn8hrqbWsRVj4iY0IL+xB3qnEG Ys5X2SFek8dRsMPcHY6RsADBtNHfl4ls8bh4WwfS8h6PkcC6fg9DBD6jFHxAZI3BJ0Q3ba4Gq6AE y5qIU0jsiMNkjX09XMF91woxQasscZV3nvZ8+iOJ9uzzYLkDHLhWVYGEHtFr2+ZCpTiyianWelCs qU70+UXzfBwK9d2sA6p9/rdWc81eateDCNFaDTzGA3U0FkPFLtuFcUjVIVldLEudvlGl9hdIAoPM fxSjapH8vWHTNZZZAtC/jzjb0GA3teZpl3dpq5PP39SNu+eorCX/SNp/yqIGaR3Gr79w7KtUukOi TavTlPY/IPVh9qE5WJo7oAYkrzPFNCNYC9jpv7TKySNqv6v9kluiNgxLlZ5/YKYP3QWDEhxxhOje YvZOy8mr/A+8BmACQPFhX+wYC0a0OsBGtKeI9sA46kjwMZA5jFakQ1G/9I2HMx7uGd2H8XBDsKhB mvFwZhy+AMHjjEMjQSPB42CjSlDHkWUfstee1f+t19lVMPsy5uRaO2KqJkprUiwudl52FgOhfDgU 2LfV/ZoZYFq+pgyQkJhCmX//dIKOizoC5KtpV4CpCYh4hnNEmnUFnZ3oR67xxsYbP6OrM954CBY1 SDPe+EmzxBiTYQkex5gYCRoJHgcbVYI63rhf+saRGUf2jF7COLIhWNQgzTgyMw5fgOBxxqGRoJHg cbBRJajpyIxcjVyfVsw4cjUSNBI8DjamBJ/6Y7KzyR9QSwMEFAAAAAgA3WouO/iCbGxcDAAAymwA ABUAAABtZW51bWwgZmlsZXMvY2FmZS5odG3tXWtv28YS/R6g/2Ghe4GbAI5s59kmtgE7SZMmdmpE Rvt5SK7EvSK56u7SjvrrO/uiqIdJhqJqyzaByBZlUjtnXmdmd5mDTxdnp0c/PTq4YCqhR2c0yw92 7e948oRHU/0zpJmiQv8W6BcgsaDDw95/BgoEfiB7RKppQg97in5XTyMacgGK8ewNyXhG3xIS8oSL N0TQ6C0JIByPBM+z6Kk7PaVJwq/ekiHP1FPJ/qZvyP4r93YIKUumb8hpHrIIyDtIEjYSMImnb3tH /vsPduHoYNeMbbc0VlE19g+ZEpTe2NDd17cZ+SmkARlMaMggUezmRFgcRxtZ/qAjikpkkJFzEBAx SW9KnBVDaSPRgMKQ8+g2KGjFUNpIdAFZxLlg5D3Fm8fqxuRZGkgbaU5ApjhaciEo3Jwo86NoI8d7 KiUVNyeB//42Y//EU5pCRMkJih9Jgnolx2HI0wlkLMWLbkyq+pFVyVv9CiSDFEUqsuaRvtfCH81u eQFBQj0MAY3hkqFouUgeK/1JP1bhk7c9RAJlnUAUsWx02NvrmfdyAqF/7+5A3N94iIIkRxwDLiIq ns6haU+Zy/AUi0YU37BwLAnPFX7jFYtUfNh7/fJFz/3xYW+/p4esBAlG5l6HPasCezo6OghuSKEz imBVpsei/7GG48ngctrpgM4F06o52GVz49m1L8LCaFEjgNdlh72EDlWvBGFZg3hDQM3mqRaQvCEz wUqA9o7eCSYnJEHjYgkJBYqDmKBYYxoRlhEVU6J8dOWXNOvPj8+PxFpn72jxWxC8bKQH4y5bHOoI uU6GH/93v/9yr6yKVhIPJiyDMMY0PcYvrhb8BBSOmERsMkFRpbtyKJg+LTcl5vP+Ly/XFvP4t5y8 iyED/QqqRsExeiiZULAxa8IVKE4kJBARxTFUWz1DigwHP5eQh3QH8cB34wQ/vGIqJjEVgb0egQqp JI8xxF/ip/hV0ZPNgdWBTfyeofOSkxj+z6qBOtXMIZlaCSPCzXWIwmhjxvAC5Xu0toDGBtDkUWNN XH0CUokpGSbaxXe8/aMJTPkoF8ooed4aNiW+9oVH68tv6blOiQNIuaxx+4tcZBjHMMYNWVLYt9O5 dQ7qPAVd5paLfhLThJzndYofWOlS9l3lghI+JJN8OMQzmHHQ1xGNFFMP5qIda/VWfjwDWItyHyUc UKZiIDHPJXXB4JaDZAIgzRolhQuaIWshobsEPYVNZMlHwFtKYLOHximidELwD2m0OSAwTnSAxLGU HDkPEleURyE1seynwnB0kJdEXfE+OUZBTXE1zJEo8DTAhKl5kTYnaRyvX2TRiYF6p8BRsfEYbPqI IU0ZGdOABxsznJfacNZG6yu90vVkjFUlGvyA55NqsH7PteHQ4f8k8ihqsTE+g6EJJUeYLDV0ZKuc TjcFhDWctZHwHjSIuQhqPOhdLrQrEIl4aZmdCWxWwnsq4q6pBM1vs+rQF5MfXBvzqEEt+VApNurI zhRwtwpFb/xnEAmoSwkYsKZFYMcxXeI7zseeIIQ85FmuSEtneM+yjIo6l9jf6yTCe7kvTHo6A10U 1RSNqNmESkyJnijkmTbqWRAgJyAC+lfuyypTOltSXRRbqNtoVmiEGE6mjmm3he00z8K4DrVXs9rz VsB/khsO5bRQY3aaiWmci2aEN0FnfIacDVlGEecUSfyOHS6yeOQ6ok+GNMv1mbHRha5nPeTHBZm1 zfDp/dKCd4LPkAwF/buulFBM6CaJtluvAGO/5RgQYGRzwEtfUuw4vSDZuZfw/oFmBwnn1fB+QoJd igweYRtlZu0b5OQ2uIymdyl8VPKZpcnNB2LjTrcmEsvztHeV4RhJm7mgJTiJvmA5ss01iGCVB26J C+7jncj60c3g+pHLuKYJfWrhDBC5ObIY83L3fafUZ3ag2vKY3DNYv/ERYEZGXGsq0YJ+WnstUaEK jrk1aO51g6Zu3zS2UYuoZGlKhZkFIFL3bIZMUGuzrntTZatbAm9HxjoAGDXHt20MuG+gxhAz8oWL tKYiHeiJuhE5neUrg2ppMmdhKg+SlGeR3H4rrWSLq5aPPRBGd7o1L1u5Eu6ucsbZvOIPl8Yp+46v l/4GspSZUxqxPF1MyJt0xZdlB1rPGX/uJridQwJjDG5DVRvc7HxSlKeTRM/EawS/coFh7LcsYmAv 2jDpvn34aUJTzE7VJF0312Qn7HwO8K0Ykx9GCKzukA1KnMfQHT1NnukZv+0B+HU3AJ/EDM2rUUe4 5PV8bOY8S9xmsfW1s7SQpu2kUWNgO4G1I7s9ATQ1MItxRJ3rfxiNJnr9AREcpNIrVVKQMQJriGEJ 4yVE7xWkx0muZxxqosB5uW3h1vrNYmoVmqWUtdZaoK0E90ucY9RssnbsV0FljJWiXWeTy1hwnsoV saBfigU28OJPEHjhfQ0KlgycQ0b1V1Y2x/0SbFtEmkk3SiWdg3loNeGIQ6mKpCBRBdnoXoFrV4k2 yWOlZaJF86Pk+7aNZEJAKVDcKyzPQGHt4yyV+KOpyXK8eES9xfr1hbZXV15YVaoL7hO4pol0nHBO Skez4mBuWsyFAsWx9EIT1fhqdEPGc2lrhqwtl/1X8TCpJ2bE4NIIjj9ZUk49LpsYhJbnMRwSvmW5 DYgY4zhDrbLmJnI21wRfNBKbL4p1AQmFy/a5txkWHdUnFgsbj5ohsVYg2qx9XItJZYNv1W7Khwaf O926ibZyY+hMMfofazi029/gG8SCpZOiu0fmjsZVv7R3WVr40l+q/rWP/Vv5fc6p1vPP/WfdBC1v W34anqw6alN+OC1PczjwTbIzExstMW2IxHODRAdQ2GFbXk6OxwFW8D8IxZkj5uhAHoXy9K+J4/fZ 2n5lWAY6gFcedeWQn1m3hSMkZKjvWMa4VA25Zkl520xbwBvCdL0pVqbN5S37D0lz3cS04ukDdzVl FqL6ZY0tXOsT5tvSimlithqCooubEH17zNRv+PmMyOtPA7/Muq2fNQpsrzoMbB2tZplftP6FBhCs 1kIDVRTb3RZWsZNAYNRTJdUUc0FaSX4ToP042mxuuYUqOOGK1SJfh/0pxQI88PsJktLiozmHcCbv /GLrEO8omw+wQI9rIK9rBWQaR4Oz4Ji+3CT93DxdV7NzDcHpyBwN1bHhoBU0xhKN7ekQoGmO3rkJ IuTo44HgLKHlzSx9k+fmIvKGcepoI3CRvBz9rjqqEfucpwH3tPu6/EW//5UzyRSdY4e+P4llohjS UNOA1jOWDeF70TF8Z8ZxPgqGxe55YjdCVx/VaB6The3Ei3t8dpCEa/8fG//XMBZ/YXWwYQCvtb9K qr3wPKkHnu1Ot2azi4/Guqsk26zlPGFiCtlyV6CBPzlWN2E0pEuLw22fyiFpn//QVdZrTC4KX1rT L/e6CWyeUVdC3gj5Ynvows6t67DvF92C7dXCL90oweXk9XVgb3Q95phMYDgUPPuXIdc9sm4QN6R6 fcRn61ubgO6Omq4Z6Ef/cf10OouxQ7y0MmO2KHaHZLnCVwHIkrLNgv+q/6wre/+5FRkoHsr4QAPW zbez50veVQLwDoTginyC5Orakq65S5p7TXJjKj4q6naO7mDPb20KQUSQ8hTLP73W8srGxjX9s86f uglm33SET6BJDKvrEyTj+fXms/UjtuFvptENXoJL/A2UexDUhEkFmPn5LcfqY55A8BnS/Jr2bUOk 3oup3mW4gBaQGL1tut6kUx0O+9fgUBmC65/g+hCc146F9SDf3bD91awtq+m0XVK9CyP2MOlGe4TU iKdFe21jPtPZwzS/5EkYQ7MooUFZ8aRFv+vTrYrekMzPkPatLfNHuzxbC9Jc5MBsWigR32RayGzX e99qmb9QNM+SyPUCS2UfKWkkTmfN9s2J2YE5690TeiOjamrNf8a6uLmKKSjnuvNy2y0qfqHhrZb9 m57E+nF5ZwsgtiFe6WejEi70Fg6Vi4ZKNs/J3bHP9bRrvIzoG1RnBx77Lg/zNEAm+g2YKlUNNaLG uchm04s2QifM9Q1Dd89NCX4djfsxyTE+R/rJjeaJ1u54NBP+p6WC38m+IaGedfJQ5zP8Nk5QPUqT 6eIoyVXRAbuiFCs+pJA666b6TrSLNled5N2o084unZvRy1ugz/3+Xgf61Ft2zyDGXJMx8lgypH6G yiMBSqZPvHw3Kefz/usOtFfecLQs5g0L2IV5FhtVrlXi9spW2lawFdKtLPd3/f9Ntuv+B7N/AFBL AwQUAAAACADdai47uz8ZR3UpBgBw4gsAFQAAAG1lbnVtbCBmaWxlcy9jYWZlLnBkZqxda5PjtpX9 3r9CH3Zr7ao1G08CSKVS5ZnxK7HjWfdUsrVOPvABdssjiR1Jbcf59XtBUt0XJCCAccepGVFzDw5w ARzg4kH95/t3X35GC35DN2TT1z/d/P73m9sPvz7aze3b6lzt+vub2/fVvT1tGBj8sPnDH27soXWG bAEY7G5u3/ZPh/OG39z+adueNj8yOgAZH/+Sw19/RwnxRULfHLoeaI99+9TY4+aTL79/vyEFlZ8i lHhB3dx+2QOjw39J6WZkgI9kU04fzUZNn/RGT5/Uxkyfyg2Yjh/lhtLpo9hQNn3kG8qnj2xDxSX9 DX2mAuMLF5jSCxukQPXkt81QoubOnjc/gq/efQnl3IPH3kKp7T/P4JLb//2+/sk2riTwT3TDxlzd uFI7/FRyufCXK/7N7d1TfR4e3Zf05vbP1d4OHrm5fVOd7OAjVznHrT1+9qbftTe3Xxyavt0e7je3 f90ePj+cts9fvDi6XElHQnTf17vtP55sHqNax2gChHlEeh2RxkQftnt7Gtz4DXSTbZPHaNYxqjBj HtfQqFeQlUuyNUWjSwW5SieXdD/0++qQybaUn6tsArN9bXc/2/O2qQZvrmqbdKlWV3l5nDeTUKwj ZGHCdYVcKzFBzkyutfri1eT/VY/dO0iwrs4nzHd3rg5tdWxDhCvlhXpVePfrvu53uVQrBYZ6lYel el31YZX51h7uzw8bZgwRzuZ0Ptpqf/Pmw40bAnm5+dANYz/ZbI73m+kjjD1aFAZGMiJpoQD5Yb/5 5G3V2U83H34K2fNSFtoIH/Bn+0vMXghW6JL59u/s7mEbQ0jOC618wHf28DTYf/Hh5h83kpUFGax5 aeATNbQQmxI+cyY2zf5mGFXf9Tf/44o/QMjmKxAuXpTPZnsgKgslzfM3uw0kwza/bO4SwOmZm6LU V2Dz9BFjCuozZALBgUUpFJHIoy9f/PAVfEFlQdimVKRwrUQwUnBoRJ+BP/XmaDf1mNow5ZkazP1L SzGqoIpuSqgX4/4Z6gX6xPFsj6eXugkXXHFZSKnTrv4NPptzINYUdM6RCU07XHINPjPPHqdGFkYu PY79XFJo976b3x+3DXR938v/VhsJAadnxgsuVjnp+ZsU1GdIA4cGyCKKdWnETBdC6NE/1WPVPu1j ikLLsuDaQ/xusB2m+QMPQRVAoQEpWnr2b4/b0+OAwZaM0IIIP+WdPZy3u6UpA6WSfqLNsWo+XnqP Z6xUoZifbl19tO3CkoNnlfS9sT0szaC9CegT2Oz8YJd2AuxmZjDq9f1xu7Q1vKDcp+5/tociIgbr +tZvbHFzDsSags450lDwRyEJNeW84ZXUFEL59fgfkyNjEGgnQvvthIJpsO9nd6gocHomqiBklU+e v0lBfYY0MKvvU1ZQMjrn7nF7qJqHeN93aupD3lcf+2MVRRgzdj6EuCYXjPCClMKzf1OdYVhc9msY DoRTFmTabh8fAx17kADlm55QUf3ezQoxy0F33LosnGK9Mbtxv0YbmHMg1hR0zpGGpnsjclNub0QQ DiN4sDdmN/EocHyWUPW0XOWTyzdJqM+QBub0RgmTGlWOzvn8m6dovwIqDmbY/O1DdYh3RCWHIXMG qM4xAHP+UH6GrvZcSgpB5jnaNh+XvVHAMAsNF1s+2io0coMYGD/PMIAu7Uw5yLuXYH+uzv2yd0M8 RGfcp2pXBSYDEJtRn/vcn04BdRGgWXpGH5g2gFYV0vfnudpXx22gRAImWdCaZtl8aux/L0wv7Uaz gl0sHyHRj7tAVofJm2s2yPqX7Xmpgi4KhM6A7R7ssQ7UERMwHfRTDNaRAAkWs2xuGxtIUUOBtG/6 t09O9vhzaMrmRnbm0zcQ+v/t05hWZ0vfayjEnOOFNQmdc6ShSa3GrSlTqzGER2ZO+QIYBU7PJSl0 TkAbYExBfYY0MEurQSIMG53z/WHbH6LiK0nBlQ9481D9FF22oVBAFwthwNUoSwOB6zPI/tvt/cN5 9+uyf1HoMp7l0BEDXVaWwwQLm/bPxfS7rIER3U8UJOg+NmHKb9OvUfVzDsSags450tArnVAVmnou SvZBh/AbgYj1weyGHQVOz0JAx1/lkudvUlCfIQ3M6oPCFFJnzGee+yACvK8ej1f6oHYLHdj+ehek w0KHl6HwQge4YejcyPKxOp2Pgb4KJsRPs9u5tYvlPIBpN8D6qUbCIQ4Ny03AsWlonQPCfeVb/drf Px3PS0tVDjETNg1NAjhEg3rmo/gcCIw09ytsmAPFRCW7j75GW55zINYUdM6RhiZFBbkoV1QQJBaE 5ffUKHB6hlkazQmHA4wpqM+QBmaJCkQJbFov+ou9t+eq3kU3cahiBTc+6K7a96doLMYgEhhCJYS4 HlqZMWBC9h+ejof+59h6J5nlp9vuQuEAJxDjeIbBYIDDZFApP8XInIGXoELaL9oYigVm+gJaL3Ux KTIOyYYQrjHPEoWAMSYE2f3qNdrfnAOxpqBzjjQ0KQTIQ7lCgCBRIcjuXVHg+CwMjKk5sdaSMQn1 GdLALCGAnmouy5APdhfVAMHGuBrZv3+6Mrco+bAdi+2v76KoYmZ+F5m0u0iz9Cz323+en47L/Qk3 uVDcL2TfLc0gr0T5ST4+dV2I3ExCgUyP29CqBWdyWJHFlqBm+20DSrUN2MNkTMzz6mKRiKr4ljFR EbO8Anl1OB+Xy0ZCs6FzY+PIatCl5RA+aHxUVKnbTDG+4enRNttqud81hHfKt33on06BOoUMcrdk 5qXq1lliYpmtPa/RR+ccL6xJ6JwjDU2KJarMXLFEkJhY5itQFDg9Q0RhcmLiAGMK6jOkgTliKbST ntE5w8qvjS+IuI0kD5CxjURLD5HcRpJ+lj7YQxvaRnLjNjgPmzYo936M5VYbPVMI27aPSxHiDNSF +anGojHpwizfNBSNwTRTSN8F1dJKj7tXXhbDI4U7sALjPraswzttQopC+sQhQYV5p575vLV2Gf9K GKK08ksCXrRtRKLye/xr9Iw5B2JNQeccaWhKorCLMiUKQ2Irtvn9PgqcniWDsXaVS56/SUF9hjQw S6IUGbajnXM+P53643nqGEGNgikKaL2HgR583v7rEnYFUIyxYQDGqKtK5SZC3M/ZndvrCAR2pVuP 9U3Pv/TF0tCAuko/D58vpYKMu2vYqrU7t2rcPS3nIBxEQMwSbfp9vT1U59CasGDjlAnbB2aXAnqI Zr6XT0P0vCwXJFfImQNi2/iXCpeqYJPp4zDEBHbQJPR0p0fINjoCkDHYx7bn7cePSyVmHOTVswtu i8nxyBG2Oz1U+/3yiJCbXBMIrbHpR1v3dWxqly9Dr9Fd5xyINQWdc6ShSd1ELSRXNxFExqZ22WIU BU7PUD6VsyARYExBfYY0MEs3IVjS02rhlfPJQxjsNAKZXz2eTN0Ov+v9GFDFw2wjIMwWnvld//R4 VYy1b58UY7+03z+FpozDqjw2ax5sIHJW1O15Y7v/ChiJgnCfNLQpzocFBo/zaMPS69br3J48Ng4v 7IGmzwpS72xo4V6Xw+YCtgyJOSHD0iM2+9Xudv0vAd2HFGdVOZ72DET0rmvO6iU4A4Xm4TqL58pr wW++4LxGx5xzINYUdM6RhiYVEvkoVyERJDqzzJadKHB6dmcWclYhAowpqM+QBmYpJIO5yeV8c1bw iwB3D/2xjm8XEDJ2Z4RIBb/KdQOcpaeji7ACUjauF2Hb00VRfZmSowIgw9BioTajAiCzaS4V64PZ Tfo1qn7OgVhT0DlHGprsg8hJuX0QQaJ9MLthR4HjM4fK1Flh9oIxCfUZMoE0eUfkuTdS+OvfuZRT UjeMMRiSx9siXxzOR2sjd3Lym8JruGzO8cKahM45MqFpf1/u5FwcvuJODvbylTs5K5tICDg9w1xT 5AQ/AcYU1GdIA3NGFLflIdcsp2LAd1V7rOKLFIQOSxsYcX1EgRxBi8P2bv8pcGCFu8s2nmF8MRUy wUvP9v5Y/bxMlFMxLHx4qfZ98AqPO7M2SzQ89QV2OnNB0zf94ekc7usru85vbFBzDsSags450tDo qCONA/hOerc9HOzxd4nhChiFj0sNcMIhfAglkTg8v6NFgdOzgD9zpvsBxhTUZ0gDszShZM9rP3ma gAAfntepQuZm3JHGgO8qdzQ+KiLcBdce4KqGuBkXjLnY/k1/sDt7CoW7eti+xMbn8P7NsJNc+hlv Hp4OHwObMqUq6CwLgTks1wTqepYgmsJ6IecwL/Mr5k11rO0/nkJbLq43S986sNVzqWyhX9Z5x4uD S1NphrOE2DYUGlO3L+SnGN6+Zm4g136CgSwyDs2l9Kz2210bOm7sTgRJ3zR2eIjIIc7Hpg0ELoER gS8tr50NzNfC1+j5cw7EmoLOOdLQuHjL8ZQnbmzfPh2ah4R2S3ebpvRxKfEmAFF+lylBu/PGCkUL LVbRaTpcuMGQ+FiRLcBR4PQMf2aFpQHGFNRnSAOzxopBnydJenre2A0BpqPRGJEaXdxw4aQUQa4e YILQym3IY/s7t3UeECDp1iSxYWidwV3+dMMVMoterh5uFBk/zdis1K2dUupnNDbXhIZLuZ9saONe c5jCac8ssHEPDtUzh3bbw/KEj7tGJmaFOff76twvd7aEnMYbZHsP4Wxgt87Rz5rAo318tMflmHdp X1Q/Lwd29vDkEl5e9qNuDdw3Do5PEDeSmZ27cBZoHsz1BGyHhN8feKYZPjJd7oIyd6xC+Fbho1Wc 6OHAmEc9Htg6/xobd7Jl/DVUZM6BWFPQOUcaGh8/LuMOakqrxh2ESw0El3EHQVaPOyvoLuMOgsTH nWwxjwLHZ7f1Y3KWlJaMSajPkAZmjTuErVsJx4A/VrvuaP8V3zB0B8Gc7iNMai18Zn533ga29Nw1 VteSkGEXXjGXdBzJkGV0icOpmmvS2DY8oWUBy8iwU47n+7FpeInDHQMp/cLXdrc82iFcw1F+iqP4 nwJjSgkjhWc6nsON3kwetgQEHqii+3H56vMajX/O8cKahM450tC0XCKPrpJLhEvp10UuEWS1XK6g u8glgkTlMl+DosDpWYrhLuqKunv+JgX1GdLAHLl0ExBFVsglBvzFvUVv1/cxBKMu7MeI6/eM5LAi i+2/3t4/hKJ6yYYFGmwau0ZsxqOw2DQ6++bCvTLJNw2v5bj9SOO7L3blkM6SjF9IEno4YIaNQ29y cDNL7acJwcf90k2XabVXoOAAcGkNMGNnF39eWdDIF57XaPdzDsSags450tCkUmJnrlFKjEtJ16SU GLJWKdfQTUqJIXGlzJafKHB6hjlP1hJYgDEF9RkygTS53fjcS+TwIrKV27ulKFgJAgp5Kc248fht ta8n8fQjPcWpZ3g3RXrb2F5wfgN/Df/OORBrCjrnyISmK+eyF3ypnRV7wdjTV/aCV7anEHB8dgcJ s6LwJWMS6jOkgVmTBEjzeQ33pckuzWEAc8cEsX1qjuBCKjLDXA+p2LD0hu1jm8HuTT6e4e6SeTLr mMIvZHiQZGZpGAmSeDmckcCm4SDJjeWgFdjwyoVlMpxpx8bBg4jurbvcT3S55CeEe2+Un1pkGqHc 66ByPDS1l8tr95LTiHUa8Bt7xpzjhTUJnXOkoelpBO5Ta6YRCJca1y/TCARZPY1YQXeZRiAI6Gt4 GpEvUFHg9Ay9NytEDzCmoD5DGpijpdQdpb6sS2ZoKbb/qj89nKOA6SVMGHD9jTHunGY4P35YNt7o wobNUx26ISSHxXHPMKyPg5IKP69hfaRm0EcvzYc+fJOx1IM8Ytvpfk5gHcm9Do/4pQq/Ym54EYz0 sxC+gMiH2Mn30zWVLE3eOfF81XmNRj/nQKwp6JwjDU3KpNc8V8gkxqV0a5JJDFkrk2voJpnEkLhM ZmtPFDg9C513MjTAmIL6DGlglkxK/rxq90N/X8VXpdwVNtdQEOCPoJNRe2WGBXRsf10mx90WbP82 vCjE3Ju5YWqKTYObx2Y4y47NIhPT8codNoxNOCkd9o2xafDd4eNaMzYLbAa70zXGTyxyvObywh1s GrvwTeRwltArTVAfh0uZM8tr08h8uXmN1j7nQKwp6JwjDU3rI/LRKn1EuJRgXfQRQVbr4wq6iz4i SHQ1Kl90osDpmeqizFktCTCmoD5DGpilj1w9r9Reu7IIVO5KJDa/Poss9XAYBwOuyqMaz3Jj+/A0 0h3inuUksrjubgWJWZqn7X5vj8FTe2w4nY2NQ5cS6XgzyEszdDNw+NkE5pN328D7i7i7D8/9FKMb oW6RDBtOdw0D89LptwKwcWRe6rZjjO/Q4LxUy4LOUrw+L2Xc31SJzkuzZew1etGcA7GmoHOONDSt u7i9r9FdhEsJ4UV3EWS17q6gu+gugsTnpdliFgVOz8S9OXtV3T1/k4L6DGlglu4SNYTlzjt3VXUf 1VF3s9FVHrK/Lrzufa/GJ7g+L6XDGhu2j8TvcniBGjaMxe9klD5sGQvg3euA/NxGAng13Db20owG 8O5soZ/olQDevY3DL1YsgFeFLv0shAN4WjA6d1RIKKH/LCzR6+R/g+68RrOfcyDWFHTOkYamhRK3 zzVCiXAp5boIJYKsFsoVdBehRJC4UGarTxQ4Pmv3Fu5VVXf5JoX00k/CckTS/XrDZWvmobry/g33 JguBzf/UH/fxS0La/dgDNr8ukGo4I44z436Z4n4pZtNLkJBlWEndbRePP7JPpOd2EWkcX76D7GIv uHbCzL2iBA+bKD4E48gs/lscAgpN/TSDuRyWP/3SVLt9f2hjWpctHa/QdOcUL6Qp5IwhCUzqHG48 K2QOwVKyM6kcQqwVuRVkk8YhxIvEvUjAC/ryyUtFudBjGNCNGtZKhnQu7cb99On0y6aXnyd3sPFH UKefXp1+XRv9+urw+9uXX1/9Zk9vbv+6bc8PG8nKm9uvrXt/mPsp0ZvbN9vz6b09vu33j/0Bwq2N dj9zvuuPd49VA9h39mcYsX/46s3N5fdWS63AwVC87e5sj5sfbz+/e/vNN1/bf76zTd+6H3vdVWc7 Pvz95uV3WZU2jW3qlijVUClkW3NLGyKtYVLTllRScKKJ4W0nKksFodbUba0AUFedrqiwRjMqKqkN I6aEr+uKcavKRupKV6StIRVeW8MBVzZt15nKGtPVpmlaYoRRGuiUsUZ1Cr6Ff2etVoZzyEpdS151 ti4t500tNddaSv7yZ8u7jgLAGKG6qu2YbZXqeA3/UjMKDAz+afiz6qgQpdCuEKokulKKkCr3z64q 4f913bS0opxZ0c3yUHYMNNtUoq4JlMp2UBumY2WlVTdkTIuXfFspmlrpWoquk6JlHRNaKVpT1loL KCtaSSz8W20lMZdcgGPAKxVjWtm6AwdaSKKVFr4CL0Lga0spTVNWqumsarmStJWQvpSNrJSRUMOd ZbyRrZZdYwRTXBAoSy1aU0J+ZE2tqphmujHgIyiGaLWGohAtSaXNUEytqqbina6h8kpoMtBIWkE0 ZJU12lBjtSwbpXlVS6qbSkPOGSOcS6Pa2radrRSpSk6htRgrLOSPdMrUpahLZTsJyKYDda8F5R20 NMVqSBK+kyWXFkopmemEsaXWqu6YYrQijSxtCzxd15SivdQ4tF+wJ4QIUzWy0wzaqYGaKRtCO9FS BY2AWEWaEliErKBJaN5xzhlngnGYH3VGU9O1JRSKUFnSVrj2RZm1umwYJUDLS0tLiDeVLTvT1h14 3hjWCAZJgA1UHOMVB1/XlhHCVQu12JQavFlLcA6UspRQKRJMykoQVVW6kZLUhpUEqqeB70RDFCTH aQd5op00wtWjZLo0NTi241KxEv5XlW1bWtLVLQjI1O4h5U5YJqqacwIlBraKMGY1lEcJaGuM2KaC jlmZqqygXdRlQ6Gptdz9x1pS/j9TZ4IlOY5kySsRC0HgOFjvf4QWgXl01uS86swIdzMS0OV/XXnA 0pFs7vld8UEPx30sxObp4dQcW82F9w4c1Xz6qA9CHjAH59S0ynjeZ5VnoPkrVmX9401j3ePlZXnG d/M28Ladvsh1xbTe0FGe/K0Vokf2PS/X+KHMD6dcA0+8W6kpfzm0b883fAf70t6TnjL3wzVxbEWp AxxyXU/AqMy6sEgbJ4k16yO8m4fM6BjEKT0cVSsfX/DOEcd+0vt2zm4cPi/n+KDHiA1qwm3w12Au xLrmNJ6nhFlLLKmtiTjzLmlzY5ujOcgfbog3fDvikxMHxin30bCorb7xGzO/LXS/FRvae4f1pN3C rgt3lHfmv5+dOfZQ+Q8Ef2Bqwy6hBH5uh7r65quBQq0gog1Li5Fr959ckQIs0igYd6wO1vXDavcz ahhQYH5kahZG5V/eskp9u8b4RVfzP4vTU2wro3kZk8EjZl+eEy5r8vBz1bxn7tzDgyaG2jEDiMzI O2zs9fpeTToCMEONMOTF1cy2MOkvtzE4q4xK4UfGQYfr4DTXHhNnkFCThYnbY2y+mePkDXiswIOF ztOs+WRM/87cNP6C8w3tzWFyJTzoWweKyYMfPm9t9fLkM3kG5IhrQQ0QkvSNePBrK+VTD/aNa5uI 6TMyTgl7HjbKXHFM48EGod+br0xYJS6H18Kuf3ut8XyzNI5o9oim6SjWx62ulvjBtfsag9+cX+A0 CrYM7UaVB3/fJro6Pd2e8Bf870ncvk+fkDW0iYvsX/2w5rGsr/GsDcN40Kz66UvO4s02T4HFraP+ /t+og+fjT3gSzER5T4jIOa/Yf386n4kW+w+vmbAoHx8xORtcgw/PM653YJPnOZzQhytAztEoTBu2 lDNCEJHJzUNjjfbgcjMa2znzNtJXOMv0zY41mHwayowtxKUgJDmGpW07aeGz+VPNEXaWMyp8FcYa 198yVzSxzA2zNCoCjLHA8XXgSKxPQUDil3E2AAg+8l43hoULU05Dx5RzkTPpFpGa8oBpvrp5t4M1 xVIjVYNXy0e/6He1h+v1hjcmi09TwAUhJeii+8wPT8wv4eb4Gj6G/6++Fj8TQIxPRwp4IOVopgfd OrtMzhQnPXmziHXGQj0K9st7vB4/WrYxJqgytg3NX6NzVHvtAuT48/sDJPNoCUDqWRuoMKMNfM6D aVrYaZQ34++QLWww7gejgU3hZb4lCsPag2SfGXGQFXOOF+dPkeHwHGSPT/yyR39eHy4g7Is/DJ96 ndW0Xiqm8HfXpbc3YtBQZG7k4bwHKIcnB13xD2rHHT11oHkTADE36Abn1kbH+uRaHgQ588oLh3wt wZ6rgWtwffrSgvUAf36pPic8ubwBCQUoRrcmbPQglRUOrwyo4EYm+HB6/fHNo5X3ebgOYNrfp2PH OeyB7+KhBq74xVoHdDrfX8AwfC08GHalYRVe+gCHPtwuhgbBexq/cADBuJHWvhe4xQ8jrb09FQOe U058ImAjnX9eF03q2LUAlsG/cFuYGexYE62gNACH8aJJKPhQIMKnsfgaGpI9/f68WJYHGFhXFO2g vhw2dritiDxj+dMeW13h+Q+4SOv3vgUdzQ/2CsmsuIYvqqL8fn0GzohnaRznNyv2awSQ9cfLgO/y +6FlPPqL30G5A+6Sq8NTBPxgjh0dAKmUz2fvSfedgwZ4947lPpH/aZ4K5nKmrI3T1AEG70fy7jMF USPQXwiB90Hfwoyn7wfbc4CCXDdGDSiJvwfV7sWNfQ1DBmiMX094rSfzb+NwAy/UF7wHRuBgQb49 LfwQelmxx15BADfzgeC48Q9xLw4PfsI1Z60wgtghKnw/OI+vfTDBKFgWYD+Tr+EEI2hI495f8F/G viEGqGzMojKUDGSEdsSEhGD/9AkIX5zfxr6A9V7+E6nlmnLjOXFpcCow9zwRAXo64Or9noHjxN50 Lh27FkZ5eWQwOp6Bfya3VzJOYoEEmr8GvntrxWcmbBQGNkDCkBrUOOKEeIqughbuH7SLM9KAN4gQ HAlQBcTO8aATfWVMFJYKPgbewkAuDAx/thG/oQKuBwxX8f6A3f3zZt2jAdln8QHujq8EvbTzIKuA noYaJmQHIfdgBHR4TjD0aVdBwQKYAABjwcpAHnAxL5ICr4jZ2wwFwgKzyQ82mS/qofRUQCqj4Iu4 yoyexss/IBHhi/z+U1Cl6LuCA5ZKhTXki0Ai4CCk/mue8YvN4RihiSlfIrATUtp8WWSSP1o8I863 jf/YA2gLxojj54nD8q11IDAqZA/JuNen5ECZtIvA4Qe+jBzBjPYu3DdIt/B6PB8Grqc34eDQK4gP GvWBCjJGJGFuee+eckk8L/LwwrEfpR7L2EGPGhB8zTt5CHwskgBqlHeXph/Btj9YTuDhW+XaGJKL oNSzD6YBy6gX/vDyuMwTUPUOu1wTcdFXnZ+PfIGq9cEo4tWrOgI5QAmQefxCELtweYAJfC9sUg8g LgHzXgNbA7/Nv3O5WGHeHbwWsecvYjSwnDIM9B1VyAroFYgfKrzgl09HwfxPEBQmKQOQQGIPGoxu XSutJvK1nBNfing1PKtIbEOlI9Y7T7BEgP3GXrn5pz0ydfzE4iB5T5ikv8z540yxPzAPPAu84szJ x/AzTbimB8QJ6IyjVvcZkIaE+WvYMZ4BbMMz6rcXDLTw9twd+AmPArpB4YA8a7Ywr11du9XygZeC LARcAaHeUMx6ubG2EzS4OLMleKwdwsbnYdITx5AS+P48E8Q20HyuH3OJ8EUJNwDuwSUkrgqmU3jf izW5Cg4IPeB+4Qp6tXnDMmkLvrxn3hrkjvpiq5Hql3PogE9EbH7ph0xg1/nnT8Ua+v1Z/R9AsmyF U7g6BLyK239SQVGL0sH7430PYoOH0dXsg6HV7v/41g5YAK4RUYFwhxebOgtHA0AD7IJw8Kb100lw 48oJrA9gcP8BdyREzo8C18jh+TdOZcPjX5080OLgHicnAzTE4ED6HqWmeH6AkoeT5/oFsgCsEACs sHV+xnsf3u4Hpp6PREB0+Ow+ZwIy/zE0sA7e93cy6BS4b33QGcRtcjYPxhBO0QUtQ2fy8FRoSXu1 ffwg7Ay3fYFJBR8WNadvDurJX0ReP+SZH175h2eBKAMDjwhgVIB5vOYSrGgtld4fb0qSG9yoERop OK42a0E4OIwxdG7+uBQGk7eQ4sPCAEiidC53XvaIS0GSr5UH/fE6iHEEfkX0NhgwOQ/OGNFGrGHU mEzErwA5wRQQcsRJel2SEB/n+OgRBXPYKd7XaKGRp3Hqh/dsWNQV/MdTWsD1ApdbmFGM64ePAYc8 UV+JS/pAMuEABf0HP81N6htQKxymVkvPiyvAUoLKPCIlAVYB7ZW5lDWSLKjIzoEo5Y3axILbxYxg PcE388cBSxYc8SzPgu8aCosGjHjtBwPwFMxXHCdwdzut/uNHvIvftjGmQ0QGKwcZDFHMkTnxJhtm GoGp+8excEwYGmSbsy5D3DLEBIPnb3zh9T0FE5yQE8DXgqEUj+oBO/eBCqDFWG1RVdIEvM0wE8J1 cRcoag5eCEOOWQB/4cCLIQs8M5C7iDGQT4QUfHc1OW5oN8YbneB6i4wFD/Aghe3BVp6okuNqNcEI /WxXg7DPAB6APZeQ0c23FFjyTyOwDAtsFTHeldfoyAIfaxAHaIMc4SAPOAIWjp5DlkF3eahyQA/Q 6nfUT25R2oNuwzvn9VNpcppP4W2R2cZfg6/REmVxIPaYXP8B2YEW6vz9TpgGYng/bhOr8/7YLxjw +fALWU9R3t4A8z0++b2xyl3hhKjKK0zjCDkPDAr4q2OP3g/zCwZRY4wxIeF98r4IccT9aYeQtcui +JK2+TA8x4eZBX/BZ7Cu+GNQfwXZFP6SMwQZxogKNGUHWIyJR9wmTjr8LNPPztU8VF1sHwD1srXc JjoAZoJSSKzrm+fGCBV9Qsb0pSfilzDX48vd0CA84ADRh+HZbrzsTdrrR0cH5xAgyxM41cy7Yg+x +DJ+rCdmQBr2nY5lgPkO/u/3gbWhQBiZrPXm6WFyHBlYM73hv3j9Wsb6EbIwgnG6fo0DMBz4BoQS RWSgEvqPqUvgHeC8gdj8gnQnRv0B/nGtC1LycdiCJGyePv6pRfZihBcExFG2AAvPxk64JQzDOCIN iDK4HUTKMUcR24RKtVM2R1kN/BggncjwjVUAllBDeFcCGYA8bkTs9BfONytHlNUV8NODA8CUBk0f kHcjcBkLoWGCCxQk3rOTVmwA1S+2hCaDRoDqD79eck8G/qCS2J1c4u9mDec9RuajPvs50cDQupFQ yF5QVzamt5lpAauqaf1FOcFouBdjJTxuM15fRah6LF5g6LS50ipsKiC+jkUI4pz8KH8YlAE2yhh5 nmLhTbF+6QAfQkd1gZgR/34kQTmfGz6KanptkM8GVv8A8YCzDyKJF3jQTnQ1a7tfcSL4CDUBJ2K0 ADA8LeCiq2QRbJ3hpHhtyBkUBUXAVydQUHtR5iAsxnaWLrAATePF8C3pfQwhwZAwSGNDTrgizDH6 m3YX72AoZorqWwRS8EiAFeDDvE5YVuwbZ+BrNj4Osf4vS7NWWsIcI4PD9+pzYK6w39+VJG+myqsz coxaxY8vepAUZUq+dFHuD1m1hFFpFUv0Ai6brHgLAuGB9QHT8JxgeCGcYD4NYWVEg0QUyDIHkODG oleEHuBkDmHyau8NSl5Whh3p1RCsdz0v0EVYIZ03hvfdaBfUoGLuuGdkCkwKhkKLwvp+0U/fmUvT XxoeNZ76KnR/qFCYxzM9MxmKl0hzq++LYcB4Bkn4hhsuuVXaqDu3AHzA+D4vfheDLUztIr4iI/pe Y6ho+EUko3TcPYfxGeKdSObP0uHFUEdkbCJ9L6AaNmhGAhjO2Wygpt66wfkgNxLw3RMuFI9yISFO G18CHE6vktFfaHXAaiBGgBZulAcEZmMyOQ3UerxdPRSf4QyyJlDShjdCqHguIPjP9KC4he97+KHA EfD9jXcO9awKX9gXYFV4Afi0mmA7qcFb9RcxxwhFz7iR9G6RP3+LSUVhOxyRl/VZmtTJWDMEcNTx qmK8CU6mC/wfTxjLVxHSIT3hizrC3gByQTYdgWLpNVIr2f+h7+/7EsAFIxbM5bTT0DA8Uxy8N2iT s5xGSpOsdUfRePxF2TI8lW8sHzA0mjeasE7cxQe3/JAHwAVQs+NJMMAmX7fRiAt+o2cFGuUh3hu/ fYwMwXSQ3OtdYEXIM/ieAwVlSxb5FaDclDUb6J7eCY920gWxYi/81PJaEPjEVWn9x4lrhlON+H9D PGAeBS/XosyMe8SnHY61munRoxrmRw3ivWSkCrAM+gPIIpTyKBD7m1FA3ur+PAKNQy3Yxi5igk2e WnECLcEmcDABJ4pxHj9kjhnqW9aOrgEic1weEp4y4pU4+ueGyBpXIj5DxU0fYmTRZWgRNh2f+nLQ Rc03c5LxPEWTIVIGzy8oYuI8ZTBY1zch0DVAxmWW3KBZ7hUNKya/kh9uoJpjGOPBtQHnu++sl0Cg TQumArQZ5oeD5OUeAegaSQMx4roRK978iQhTfDsYG3OGYwlHjayYc+SpGHBcGxuC1UC4NzgRHBB9 WN4EfFPw7SN1syl1n//JsWPuG+x+BNk/LhP9HnP0uVctN1CAwYT616y5PsZT+gxtmYztDeXlzQCZ /EtNMcwCeDU8Hrk6AFzyekNZuGwx4IuvElJrLWGwIQQB8EI3v6SeYxjPXmpxxHghjgg7dx9NILck GhAkIWpLKYuwvwZM5FKxVJhVwAskCJWC/j51t9NrmgvgzYPPjE0Al4FzM8qKwC2sBnJsvBDfaohT ZoQx5NjhCOC5YXASvUQkUClYwhJRgrh5F6UcnMO3v2DVEECoAZ8CYhqY2ffpQCrsoPwAWDc88dqM QfMieHoueN4cE+DBf34Zo4XFeIuvFPhVjPN3Y2qf2W4UQOmcXe+s/wDc4CL5JNHMMWMI0gQiiroz MonD5NMn8AFrBFvlS0GjwP3rPxHCAWkK5TIlKMEvTmMOBZrHH75WXtyYRZtIXY1FS4rUnJ89RMTq zSS+N6doijz1YAZ7fbAe3nVcYKSREN/uArBG2Ezhv7zHF/zj3f6rCkn6BXwp3hBj6T8N3gJAvaG0 dFRUxMMwcr4QPfwycI9Y4wHdwtEqxPpDXOBLQN89zYxiMpHJBAOEoBsInIb9edxofLOayJPTY6VM tp7vx+o8GowyH/XAs5qECTAILhwCAQEchFjQvg8/iA3CiTWOCKPapvS535wqstCkLoBofDDgD2wN rub5YNWADgm3tH0tk0pRvWumQFrJ5UTrJbLJXiy8uD0l43oPDisIIr5606MoEMpxNGZBHojlPjM2 lLahCqMYmuF0wSaoYmumx9GzalQVQw8/N45cHgAz+GlY/WLED8mqC+XnZnMZwaBUMiD4yxVOC16M U4GI8KS/rDMG0nQJ3A63+wKsAcrZRCM25SbvTj5mvHVvN4QC78xmUvsPC4UKujboFhpQ2396xnrC zb0ZIbABK2woxvXduAeERlyJx2pL9rVMndSb8Algf3P5Snc1GDcFFfghpGfPAtRunQv6qlHELAQL OZnNeTOfwEvj2ngCeK6efolyv+6LoCTZbFoIq6B5mGRYVMIbYW1jgeGcoeAg0yb6YKEI5VD1/7d2 KT0rzAlYtfjrMvVfhg+T18RjeRZ971ZezWFx29uk8SNniCYXVgFcAVfKAw5BUefEfd2vtSoNX7QM heIiO7AI7Ye4b6NlAFisFjqE8cUUXOgRbmK3zXSDzFj2Z6vFWFnIejQK8ov7Rr4IB/TM/cNaP0SL Lssn9k2DoJF/+V+uFFhZkIvn5pCBhhFDb8L1J8EIXA7z+3iKWw0gnOW78BaIzC74/Hddc439+8Xj ORKuGtOFIRZDIq3fLyd3Qc+t5cgTqwEBLHguxX0CT8Fx1mTc7Kle4+mnzBsh5OfwtEiTcX4jASCY T/pgHdk7BPi/LD/29UCbn+HNdRGuWorh3OC6Bc/AgLdX9UvHsEAZ3A8WladI3IGlM5CBwmWfWRN+ zCzFLzqM2Owf2qiCiccyLfiVnwLYBw7iaHC601vcN4m+rYVD6ZK5RS6QY8E8Iy2/qLw1d7eCCAvd wRGQ/om2a2bmax6E38EgWsmEjJtQeg50u4q2gWk3YogRusbkGfP3SPwGfs5aA4yypy3g44yyqSvj lF1Do/QeXgORxrHzCq2C1LlREKfRUATVJzGnFfi9bV5akUUAlhHDbiYXcI24WQL3/aLtDweBTm5j czKObaoYscDavngns1FisFyFVa9prAy4D4BV/wjUIcoCtPyL9Y3TJtDQGpdk5GEd2HCJhe/HnT/a eb5XyPnynp/4BzcI4UrmoAGzXmeCjklzcfwgIJgJymVmMwaTrDyp9hlDhLdYBR41bnYy6/iPtZo6 dLHtxen6uWi14GcqA2rsby+vUuo5YCacBEqDhwDccNAzeWg3ejzFx9iNnG+xTptYdwUL7VXGt/mU BylH3DC7Y/6wC5botGioAP2E2OOGC9TlxTbF9PjYWP0e+FjUDI+C4ce7Y8ow9UaOzEeDlFfT8u/R fpmIad5Lwx78HWHjfKwNwNAmiULAu6Nsquzkx7OBvSeAMDfA0EoKM5ww8F+uIX9b7/eFV4Ae/UiY zsbU3aQCf98sWODBsfrd4IecthglvrnhpRXN/iR2BMky2sHrJCTwRrDBaqA0hcf4igGQUX7xImAx 57bOLzcOaqv5TGB/Hr+aKVx3w+Xfg6mmhS2c4n4KkgWGwJlqgCEISr01fZCIdcMzz5sspOtmjnBv GQpvcO/ZqXPFxi+5SHxKyj9WDeTSIo6u50APOSUjta1+HK7ICcxatC3ggKCMAElQhYhtBmfKdg9M 9oaoLIHCIOYvptfiRJDYj9u1XyoH+4nGNKPyuG6+GM/V243g8NiTy16wC33M9rgqnhKFTb+qxwOP MCukQz1R5MIvTwQXB4UHzmbcIM5SHKsScRIA5rCNG3JGpeI2oLunoB9mwgSNCG42aG8AGltSvh2k QEZu8IE4kW4Ulxvj/4mmDPdGo0Z8RQvcqVbpBuy/jc823gz7xHW9xnHnKSCCgasra1t+BupF/6G4 fAfI+rlB5Ou6IUelvAhBBNT2FvdBsKyuwB70MyFYEw8NZwt4AZw6EsfxIhgd1L1xf8AlHuzldMx5 wX0rv4JFeIBo0BusFsac30erGp+cOb50+DeYGDceAU7g4gQ5ixZoGUMwlsuNfdxAutLLjXE/mO6O 3C8kqSOhFlcirU0gHBf38FqjduuXcP1YpQTjw/HmZHwDJWvvmb+6nS838+t8H7YiGB4bJa3/qlyL 913iwWciEBMMMMA9N7EG0n8AVOr6BcYSFg5oYO5giLz0u4pOGpCH44ZhZc4Cos5ZvdCE08CnDecL jbbUeJh1SoNXkF2BS/Hd6DukP+hlK77TLwZ+vvAmTsWyDCHIrQmZDw4aM4ZLyH5uxPIYZebH0el+ g6oFutNe+DMcNx3rOIACmB/kicv3T94SBMhmzSZYBzCpTzh/9Yv4UgNzPFBfHVslkzQInvhtCy+A aF+aG9W00ocjPDjGwqklGR1mZ/fxNbjBK0+IsxghMk9iHLYmrnaZcZ/Ga4wH9QnmTxY0c3H8XzB5 xBFGQPbL8cR5AhihICF4FCsHgPbv+A4QxcBnl9kiIID+X4X80YpjUnsfXLkF6GZnrufgUnHSniJX z4MAchYQebyX20bOLIIr04aE7ytVEuGI6+GiYUAo/6pWcUQgVylQX7BURF3ia9h1I3UbVoDFL37r DI3zwigCq1/wFgZsoCJGkx41IuBzJZE5JD19hUqupM3KLYZesOcCLuTi4Wsk0OuxJOlWjxu55ouQ 7IQ+c8hA2xHiZ9RTbrLT4OSygd5lYR/PM/DUvK6mCMmNUrFrZBBQAKOM9eVakVzYFP4E7UFLrdAE z+NPMSKtSrdgAtFkp3wLy/5ZJ7o0PPwHn2dmK0ZTcPJ5/lULXi3OQfLgPVh7OBfSCrJEo+YN5Q+A TkJng0XwAYe1Fax/COfjweEUUPAU3oEtSpD09BzM3DaW3rCPlmSAELALfAcnlgEw8dafbZUMHDvy vQNOofDwRTKFOE2LWj98eras1lL/D/V4RAQ1VkQWR2qcDgqLvwTRNjs13gKJtEQE5KWtxp5AmIZh sYQZ53NB4FjF3MCWcMTRsYVbQvK2mzjBYVwvYIirybEfcPR3OzfMfR5+5IaTg5lRPgaF7BH/CLQT tVmbMvFrlm6iUZ/WED3nwawqed4tnAXrYsEMC99eCYARRroZosvVGn+w2+gvN7CwDnqsUoOVbDYA nHBpe10b1bP3BWZTtAnoKAbhcIVGYtDBfUP/X/v//pSFm7iVQLiYVRWdijM+EgS4GRKSbkUfjm81 DNSzp+F+YDmeKejnRUj4GKzkBzEWndhGtO8LAElu/vqVM+Egl1lQzgc55P8o9Vvpa4YGmkVb/By+ XwK8ozUgGfxz462RwznR8wX74hx8z0cBgW9hH9eArMAzcXsbOzXEGtA4XAjYJzwQ9MYXA2Cm4olU ZwEwILPD84WC+8YqLDsCyYoJMWym3RCDI7uFJWFXeEiB4ZcyJ8ohGhOBdBl1QHQtmw8TccIfoS3d uhRgPNo/Le8yM4WX3GXdQozmfyE7tz5EQ/RacXUzMNZQYybXZ+MG5wR2To1HA8jhdnl3NAWwZY3B AXC/EsIYbkGSJQOvNboQPjMmUfKAEwO29SfzaDh94cVjMfBruZShXeP8dm1kw35WCH/jAWyWJ5S2 UeA9TjT4sG3dgmO9hrr8aItA5AANR7BR7Q1EjjBx1Me/BPVM00W3CwNuUPdOj3GYyIODYZBizHFP xmgADm8+oCEszYOXtbKmWCJxIF6Gxl+M8Pcpyf7Wx50cC7kMpPFDOEiZgBUuEyOng0GsU7SLKp3x 3l4ofgIqbmeRxgvk9iwAPSdcdMIfj2BZCc9n3UzCUibufZjOqFYwzGk+COY7YCHWEOI2Dbbb+LZw 3deYcr5w/sBnod8GCdAUA5odVUuCkt24MLAHyAEowZfPzcFyyeAljhFjflB3CehE0awyxSy9aAQm zmgENBajCPtFEKxY6xbUc+JwbjA1vwjV6+gIfhPShFhCCriuF9BeLOq68DhjmRqmFjTEhSQMoi1C WHpkH3g/YRhYctS5IYSfniHxB6dheRQHGVtFaYcluN8zEGewoT7awvFksZAvjhIfE8U3Nz8tPj4W gkBnq5XJyLK1hhExxpFixF5ICLYjJrTBa0yATRFfPe8WFPJnzb7DfYD2xzoJa2Bwocnqq9Ssj3m1 5LjGAu97TS6eA5/F9/ht+EpObDZeGM4UWqs4Y4E3/jFbjB7gTwCCsoAM+o5lBhNSAoH+4O7bkqtb SmglF0ebbuAQ3NOwg6pQuH0EAIc5X7Vg2t60oyGPa6zQHDSyt9INDnMxXaz0aWxDtwjZ1OaEjGeu ZITqI4YuD/w6jqMmo58fVlz3l+CS2WubCBgmPBu4tOjumLqYhu0f08A4inZKh73BZe3WKIhWNqAE v88pWHX1IyoFu4Gc4H2BCfAvI/ZGUqZdhwcmiGnGEUA/MLdHls6FA+8EUN+HZeumtebGdfHrXCsU fT4jLjN7GY3GYIBXV39AylguMyApcSYT1l2wxS3jZfOOmnuQm6XiwI2BbcFOyAVWwbe/lrt3m3PA 3uCsABsIYcWAnYXcH/OlBfBVeAoQQ5MQNHD+eSw6AvZiGRL+0CJTsEU9PVrrf5NbXGLs5QCU1G9M u1lijVGChUJph2nX/vKWH7QNCj0sXH7NtRlyfeyRWPw1aFIlrIa0UFgOOpQELcSAVny4WmvgwGZD y22rJViWPgF+OcqkTjX+0BCVzXDYWAFMF+2AP5Fn6F6H1YJFOQ58FOZUy5yMBYtLN2LVhcwmmiCC YEXTdxhHVAE7FyegwhBDRwWRJAgQWlQB9dwrXsLbTdgjHswsW0anxKjmSHFNX7iak/0JFN5u220R NxrMm+P3Iaob4bDdkT8EPVoY2XxeX+fDbuU1kOeMX4DI2lIQTHJwdMhesrYTnQQYhTEsqMIpW4zP TeIktd4YOTRyv1aWWaaFe8eKYcEsUoGqy26AU5p4aGydqCa/zGvmYZF17VfwMDwTY4YiYbLLOCDt AS6axtKLnUKAR3zbs3H2L1gF52ypgkFL4CVGlBvZVXgvoYcJ8W0vuAdjVm07QUlat16k2V8Dtp+Q OwAzHgOO0DAPx/ooSwtwWKBGhMc4CxBmryQMFlu/GW8MON71nvDhYAYPAzbEBA5LDZE9uABM9tgc qR8GHoDVeQHNwZswnAnIbTsFTh4mGd7dsBpgzNvLCWmzBmCcgGlZlqXUL62bXocUGPmcHUrJiQ97 vEBcW4MEFUDSOk5RvOef2zkwrpfhaVE9OO7TLRLIz+0fjRU8ZCBkwDmwWOYgIZ0CBpwfJO9gF7WB 2aYUK9ox1wvoy43ktHGPwK9j28oyoGrG/IXfwmLwrNkwAOSYJ1z4w88EfzXj7v2iARgKKzUSXv9Y r4gwGL/EZoaTP3TKiD/+s3wa5s8QWDSW8lpgctuJgQgGWG4dnR0aE6VYEVTRwAZ+RrW0YlvKu4OQ tmoVPp4UiUXSQlQ4jF7fEmCIWtmgR5T72N9merstuxCy7tSyzQ84gNW0z9hn0SM8lgekyxQX2Nv8 gj3m/QUZfKOim7wYIHwKhKFE6WASBpcEYvsgyQm6AawHgh97ulMvCQtbTdCgUdazdHBfPqaTMQWf GW3r4LGVMF37Xl9jEjJUMFS1Us62cK6u2t/w2JmOq7fqBhzjsYwmO4U+4tKrHRuzYs6x+da9HoMr yeK0sC1KzhwdIBe4h4pwj83Qqr2k/CtfbVMXzAccYoDplMDHVVDB52GDZqwX0jWlaVUpDgNCOaEu y45aNAiLAXhBEm1DxLRrIYewEJldCHEQbYDeIE4ApBGswLCywqzzuyZ/wt9waQdMXEWaIMPb8dvE 8Pe88DgJpzrjDXTzoC0pm5oFQOsuZXJTiZt+JK3THk0MQYhx3jIPC3HRVZihSWMQ3TFng5jI37QB gnl5PiKFH+OkBsrmeS94pulyzFU9lceypxfHzatir5XeGM3WmeKqi4sAEOBMN8+Ao1f+B2w041sg dEBW6AlmEayCqJlmxHJHcy72Zr+8K0zIWzECO2/+cJly5+IQ9GJLzIHMBFUJ//JZFm9Dt9Mmnscm o4O7AW7mcEsHtb4xnIFomTbg+MO+/ZL6YJt4fEFoxGtnrMlXqSU4aKZiut5SkPpgXvBogLJRS+mw u47paQYVYTXDeJReDIqGbOkOLF3VufKj0dK+wM/CRW78hKuyP+I2OQ2UBUx4W9un5VMGV7W3nDFQ qw5jWYCfD6yMg+F1DGvCU3BqI68XWwoh86itaIfW4Jpwb13tP5ZrghYN98Zt6e2xofn0x+CR7ayc Zb63aF1eNhyF8bSbxVQcalQfC+pvy7P1O9VGjYzKRusI8CsTkfE9ngxlhBIBuLEKjj04otVkwQcE fjpaoHeTh8h+sm8THVla5a8pQBskhE/GzSUM6pg28bdfs1d7LJLbvQyrYJp9ydWwUL0VVIWLG3z8 up2y2NImWgYs84Jlb4DakDQFDlB9m7aYTnhD1upDE+2Kzd/MPANHZb17a1iPd5pwDdapaLGw3Y+G 6bXog4OFnuG2Opgbpw1vxpE73ACBsfvjpjax/xx5HjyMlAoSjEpgYwCLHcWC/3zXnb63pel5Oxra nB7R9Ms2qo/bJmokC6OHjcV7v9EKAtz0tLkoWzSdPrOJ/K8zA27JHyprvRwvjJY3T9XUGTILHoB4 gNDMnemwAa9w1sdCCGP1z21R078NG9j0YhO4bWkMUtr0Jsb/jGbgJWTSvCMCAiSpDs/Y8lWsLd4E HotBsCKADwXClel8CcuGG8gGFIfbQlDsyP0AMqYfYU8GFT/eP/FEuAlHEvQJorAvNcMHarZLFkVO EoiFeW7RhAyWDAc4ITJx3RI7/+Yxy5atXgSeDSA8av9Ex2DwSZ/g0gKd6eCaqkL1D9u7jQuKwzDl kLNqN5r1jMBIlA3wPuGtWBb8ULfuL1gJ3gBkSeyWIT+49mDFCqIDquHQABmYM+Ns5VwCBpsC8syS 1pZQ2OvXo5yeV+/FwSZIQsLvrm3p9rihbHxJ3SafOfUDjMWddKd3INADJQ/StMTrGe4R2A+8BhL5 2mtlj1hbCOhASky5gK4syXs4UZi/OI5TlbAbeAe2oJaAraOWWYDy3irGq/fAPRF7tKzB0hTpN9zd ni8jUI6GqXbEg1tB3MFCCwzerR1NXAN+AM3r3ea514DEDPsB1kTUfHlvE0xYLQmzQBALCw6zdwG7 qS9vt63VAUNIFgoRliUVE3dg+QlHUm6ipusbN97I8qoCkr1NPMEAX1vmPjCioG08Zt8OKTDO0bM9 uHogLnZZgzTnPTus6M3oGALql694YTaxTB4MtijyuvOAZN+9GaXHkVSLjrEBi8fkyaMDRizWfx1q Auk9xt1X/ww9vgEutTs2J1qwjZCcy7kxe/wLwAcCIkeIJjAwEJ6bN32ufpg6Q7eLw26gHxn6F77X gAgg2UQpx2aXt8UIH5J2bMTHeyGesE6ggC2WjgyQdsE5gE3IMjePSIH6ht22xhMH6tv3tHcf1hdm SssuKvkt4jRv+AG4hb1BEjd6l4yui1zhhglajJH6Ph/tupePQ3hH5fcKf2GDz9dMewyLG8xq2Vld fjE/2WiQXVtYdZw4crui+DAnyUAGywY+zPvHpxsyeswjPgU4Y5Jn4fHMYvFkwTjDxMwcrggDtu1k x8F9slVYdlxOeTJcty3Q4Y8XtuRDBgAgGGz4XHtsauRMB2oKtqgmlrs5+pnydJYLZJu/h2zwNHhZ jGe8ptdYJMTGeR7vdXSfCA9MbPMLkN9gh5OnQMbbRnjbgvgFjl7bjmvhcjA/xtX2t8X0t17RMUzV OsFjOPuN3t8j5g2IiaVNPqtRT2jkWAEAZpWnCoPHt5PUsVHLgJv1z6neEM+XOV4t+3nHiibRcGEF d6NF2AljGe0mxUSBYroU2OkXN3jE26vwKJjBu0+WiAAFCysBmjcC2iPU08t8kzUkkmgD8be6+pgk ce4HlIMPiqLxNCqniR1FkKH8AFFwm0nhOEDyCSiIbYg2vvPgRljAkDYHrJVtZMdS8ePTaLWgBa+J VbVzpjo0xByHRYu2NJ+FMOAerMg145EtbY3gmtufPjJ8pzZjouAA++2tweZgrfu73Q/buRQ7Or5H IvI4luJwVybrm4md6jgadR80Nt/td1kjvKTF6JCNbvPyKZPL1gQAsTpf+dld2WSYRmU+u4XwQIIc AYhDUXr/8E7DupKh/bWoCu3i87FsUtqnWCXwlmJbg1V+1rbeunW+YVlWz2MFAA8yzndbRFyCXeM4 s3bbFCcSAzNTkmCKVQ6fMDSiqlsNijvk7heWFytdgfFRFeVIVeUdP0X/ibjZh7vGFycrjSxgDh3T hC/EzuBggfqP02m6zRv47Y7engpjMPl87oATSwiQ62NVvrNkBkoacSIPVi1P5058Nm68Pp7V+g7d aRwI1t2IOg6eQ3LOhfktKBugdG/8l1k2pBqJQdhhvhbCOAEGVP98493dfBmQZn1b6w4bg8abmOXm w772wAJjDBCCDG0da9/sAY9j+BerYKBJJsINZEWVLwcFeAno7dYIII+3XNfyGstFTZLymSZMkdz4 WfWIA3r37ZGo/JEtMqIn7LBVgGXfNm6TgoBaowbBUteTL9r/rIowf4MCFTBbsydkG0JHOKBCACye I+mnthPEmlNovOdakXNMVYTbJq7cmgHr8U4sC/Zoa4qmCJfGd04FBcduB8fBa4D2DlS7QnUwBNDE MFZtFryadUaJIAA4tYo5tGWP/8aviTRN78AFrI2yk0cRBAMUhyTA6RxB1pL+z7JW479ArH1uZ5W9 sbP8+jbuiLt0u8ZxM5gHa23maa9M4oOHcWG4Pxu8iigWaaoWJtxOovyaBXC8BNRrcI1TqmM1IuQF lavcDx79AbB0k/rd4HLEgtgUdkZ0CJJRIVwjZgomZ/kAGB5nZ+EmRrlrzj4jnKAB6/QApYq7wNO8 79QVGTbDRQDYqv3oR3oPzLuzRqZu0QiFtZLbzIydScvvx11HM8fDOVp2/b7bPPQGKGEesUfbWTEn Xvjx6241hcxVI8dLgH4wzdbFhemwke+Ol3GUUjbz9kKl42MEOxkBOQZa2kGzIDCccGjgu9c2YqO9 zbaPVTx1eZaB912sZTmwj/XwfTbA2tj9fnfOGTiiJ9hOXsdRZtI6p2+UwGtiAcEflvcKCke0bLBz RxF7DfJJ74PQAVuboz6sUkF+zE2YPOZK+R3cjPmkXcudK1E/47EParYfczJPcIhkC9c/9O4MooAX sKx9Omki6XHxM4A3PCrCicDLDLjxz55rq1g5rI6ZyMASdIELzDKye2fHiTUGbZFhIdBrS0/mx/ft cd0vIJtbTw4lMO6Cco75vsV5Aabh8qtuF0gIpgWjhWBZ0csPG0ataYK3D4hXJGMiTqSDXYNHdENs G/BftfxNCbMRKVQ459swQu1Y8WlM/pj5RHg4qGB5ZuDKFPRti5apEqymZX1cnS12RxlEdrnGcytt IPa+g81FZVjiZCWXxfdwY5yDDhCcgK9Cwu2rss8HyUW4eXDMOgTagIotehHcynXV6BgpRPGxvHAK 9HIFB0zjWMXk9cUC0F/7xisu37YL++LurB9rWzA5NkF98OJlUjIaM3cgo74NaZpGGAQtQtI0EQrg Nd57mOJCISHWUpOGk7V/RLo/LH10QE9YxmGukgBam1mP16maCxdsB0PD2k58+2tpqF37jqDDANlS 9hqdbtpwC9xbsoM5mP8CzTjmBosG4bgVD1hGkFvZDpiJqDl2Lskxq02QWXuPZS3YUmAvDtbyZPMS wEGkkKOVD+GDQWU8HHLwLWNpDa7P2yVVO2948y1tHe8PIVkI78SFPTfc5THwP5yxhBw7qW05Uu1d 2VpUcByQpwBfMA6cYXo4aiTWREC1JA2zbrgTsC6wAwqsz6IxaQn0gF+sOAkHc2BLbL0CwfDRWPAX D/BIBHnuL9wEkRGJYU85aujEIANny/ROO9yRwwhQmtu3AvY0Nyn0r3cCAq+AkzUMP3zOGkAE2U42 a/rK3PjCKWYttkylthwFUO01qQ3YVexYMjOplzRci9rwaMloTnmKU9Us7TLHJ9aw3oUXLQg2x86L NIcjov8YDaNTSy+cTrsd+uggfsYiMWXwrVjaEa+jxFCLH9ZrhebcjzVlavItIi6h4jWqs0Pra1w1 HsQIX+IMkwqTMqMfnOqwHfSjrYtm5KY5lYqn1Shmrdt8AsajOVgKvQsIqe28lrs6uAhU/xpa/Gos IhcDxviEjh+MUlrpIcQOpIR3NDQdyhjWOZZVotSGnwGENIO1/H+bGd8wNC8XFsMAoCb8dbGjWfOd kcYI7DrQXgdd8tvm3uPj9GDAk70vDjTh5+3V7TZQYnP5toEh4HzrDepiF7ZNjbsasrN+teEb8buw DZnFq9nmYUD4gL07p0ScPQRA7zAZa7cXcEN9jM5Om3fgrtVpxhUXaMF+STuPwEH8qzldEzTbuSfZ oakIfny5ZYA/FMGhvBwlwjXAaNa5Z3NRiNypt22Cn+94QRt+7UFciI0fxkMg1nDVz5kUyI3ZYUwi qHmaI+Azl6c17BSxAvY4zQvraCFKeErnT5ewcTjqjxN6n+yYl8Cp+bvTycm8gyOMTI9k1MNSXXAj luTgbC2hTjjlbMnsh6dsKGSaTtwBizu0BAD5ZG1ScEppstqXC3lNk70dOIEvQ8jMktzKc47pRKsg HlwFbnOMad9bzzejZmzM/kwTqLzIa90L2ALQp7u/iBbZeFM0PxVs5op43mQBmY25kNHgiFxOyMoM ZCEVZytwYevyEuP6+M6yXkeBRvQr2pr5mcXMjpZJ87K9d70PR2ywGMZvihdMNkdxUILFfRCM6e3b WQrx0049IQRHUgeD22ZfTcFDVDCbyHk3qeJUtiOTsT4USwVedBQf/tAeDPsb8V9vAubg/yOig9Kg hzaM8zTD5w4WcLdstWB9P2wcMP6zAENiCA4UZ9mwAJM3QGstmWMRvBqcKhoLx3naX1wCmT5WePGN jmZydix2KU5c1sEywyaeX+loQcjXJ2Yfppx7fSzgQOo02rbRNl3Dc3sMnVZaePlmkQ6H246TxeCe 1gPwG7wW2qYHAHagqFjUOWzFsq92WhPm6yIdwOeMEXucKA4xGU4tGwDWvR8bX6LYpXG2zRYhDGXC Vu2uqOru3+NAF+XVocm8AwYp2yb/ABUug4CjD0kuCg6uMazmHIjm8Bwn8zo2gxeyfNeRitYI1q/q vM3YP7zcWpKkzyrRjlQDU/DOnJJFE6ACEOhaUafsUKFoUcaIZnWdWoROPOsOIH/4qo0PB35wIIDC du48KySOX7FNuF908HBgWNR6nb6Q9XMCFIigzMLrNfE66N/Bl694JBnef/0A0OrNC7ZhkvYzJWWg /o5As8i18tTHjANcLzjPAvnfGnDAk24GYjrPkjFuzBS0xfGXI2lOUPGRjgNHoTc25gHqv+oEQzTZ 7lSzrbeU3nGA4XV2R7RoHS9sNMCxRo4E+pwJfQtmuDv7EY911aeeBhcPhlvHrSoFDfuBYNf39g+E jnJ8XaKAZpgYRykdcJ2cYZARGcjKZ52hPTdOTO6WAwjWsBDcrDMyIUvZrh0hqlOhHKFY+OjquK3F AW7T6Q2zYjVGXg4lOaHYdZyCNhUoK1ird4i0BgI5x9if9wqC6UbjtwhKMHHAKW278A73CYBO1aGR 29nQIgIEMw1Hir8odCu4Zb0w/Dgmx4oV0zzB+drls/3GCei4Z4vsi12WjjtEftF0vN0LirTJE7sJ rv4CuHUfXDM2mU+yc42/MOH6mh7Hi+dpuNv6PHBDM1D2DoP7HYUJ+O744JejTlv2YR1LsWUfMudY AwdQ5JOjla1jOensfDHzKSDL3GwagrcAZWGCXGuItzTawtH1Qb1s07ICZVVn7USbhH2obiyYE3EC fVWOkoUczQFPxuLvJJdhcZ2kuMY72t7QnvDQWaG2mg63CQB3isPpjzJgcc4ZWCqHHnN+VrDb25ku xbfUrmIGHBSCbxrWHXkcth46ChLgasjuBrxBTyiE8MAIiRM4eE3TDDdD+8AsHCYJYn8cmuSZOq4A 6YOlwVhESpCqZnghHuvbtznLX63lSR+WO1k5u63jOp8TifghXm+PYuBMB+h4wG7HjkNFeIqIDiA9 H4CuWKUMB7QFJp0ELwQpAkgEpt9xVq0zqh3mby8yeoWVtcofMMC1oeaOoCzOqK1fqNUuKCcTc3YP 746H6Pbw52CJfLXKzSYpx7Q6jro8wVp1T7WB25zQj6OOd1CAdW+guuHQhX0nM2Cl9GTZivihb35g OH5fHLaLQHXlReBa1GZ4IN9l9AfFeCxu7tlJKA9I8LZsJRMx11SEZVjGybwHqGXF2zI+54R0jA5W LIPMjrOvTZeBdJdZQ36haOTNhBWrI/k6BPE4ti8t0QyPi9kDuqBUQciMJD+OU0wx2GCHDgxMzOd4 0epGBGBkME0Hu8AlQD4cG/PZ0n12fz3uz96yBKV9sN8YQQsfTb+VjZiYMzekU21KeM4wyvjB6qel bdj+O6l3KDHbMVOcaN2coCUL5n5et0FY4iN8yKlgg1BBe+a3WID3vlHMichmvMB0O8TJ+DRstFGu z0FjHLb6wDPiQB7HH9pcZ+vVSFwlB2vn5DaXf20DVrRA2M3XdRdNZJilmXuLcWcKGracnCyM13vX tG4qOc1JfV0NDC3Zee4YrW6+p3yW21pDe6xHt+XoWvFmL9xxYrsLJG5BqDUCMZvp7cgGkBkpSo/N gU4SRuZxGGbQu4V4j4FsI5kPThEn0LR50b0Q5smMEFqAPp2SOB7T0BCBoodd57XbJR9bcYwbicx4 FC4SSStYQy7d2wPeTcnGNBqToOGYXlj7hh2PD2k2iyhe7C71EOPKeqs1vwA+JMlGwt51lj0iwYaE +Hxr6N9lFf93211nuLV3PQQVLJrPBePe+o9tgRYcpdxWRqB3ss8KBYLzO+rHcRHH4XW89XblRHSc z1mW4RUnFL+c6EJqJPoO+3GUf3stmuCYnNEBNUHH+h36IAXGU3Ov0/UOU0p0LOO1gLMMy4Nu3vJT LCqs8HNUazYOC5IoWAo4kPndb4JTvjuVxYN8B1D0gdMB0y18hpsA2pKJeMQc3IE1fJ3kOovzAD7X fYCAEEPMexW0m9RBMR2TuqzQ6K6GeUcx48D5gs0Q5y2vwjgG53wE+Ed86imGNOzXuTWwOEOe3aol 7IV81ri/Bm042tKQsfE93IKj7JxZ5dw5JBGzl7sFm64xcNSHMoV1hqaZPh3D/kX9kjUCDq0/qKej S49Y4vtuVTGMwYpYR4zZo2QPoVUWw9IoAFnhZ2zmPwBqlYNPMXRnp8eR0YOPeQRcqJm+aKoAP8c3 8UAvSl7unLVqFawB8xEdZOrKHPTNu5STgZAAPpjfvIEyBeUwTWNbKEj5sUmi2tpqqzm2AR+4i8Vs AGDrZq29jDJv64B7tL4RS1esrPfo5RQHJ/cidtzhuoks7IB+2f5Py0oRc6fIJiTAyaGvpUh2nXU7 avjXsm+ooNjI4cAeaFtZk28qN9+JqeeI8p0pgniA8e1ujHaKF6deLjx0c6o21j4hbiCf42CLaUwO +4QcPClahoy4OgTfqpgA48XQ3fbaYmftjW8NM1ZOwuYAKla+PQb/3ue7s6jsSt4p3OIdk71oWD72 QW3BjIkgaAhvjKgux83g6jFXKJnh4AgsQywsfbWE3QhVaPm2nziTu1nMv8x+dLzXMK5gIdjrJKNu J5qTt5sTKr5k1R5co4ooePWbfgK1wMUN8L/Hqn2AkTVgHLjF9O+ymVkTst0ss+G1870dgg5bt10v CR95P07ps9q4gCy73UFc6Vu0hs3lQAZSeMxgOqxIyDFx+FTYKZCIK3V4aQn2xdupeduMjFPDWG47 z0oigNuFZsDbLnaL1ZxatC15hA9l+Dk3jF3E9DsLJ1kbMO3ws+LPwJIxGuhmSY77BNE5s3B294c8 2TLianbVsvdvQu4QowLXx3BPUei8cYjPNQIOue+iXK4aoPDZwG6sprvCQxY7HaJ1eHC4G4hNOIEg 5OP0IRmiHZRrG6ey/ecRQOk+gb32lQOvmlmwark3ZwBYSs7R1bvbZm6NGDDe5Hu2g815po7v4UTN OvG4I1tRDXRyHkuEJ9hsEo1YQlluiz9eAMVAV6o4uusAHNHI6Q8zGHfs57KWcySwUTXC/GBlR3EO k1K7wQfxxhsx2Q5q5vfDnRnJp312SBjnbk661eF1gI1nhXjxSxacGsWawJd2+5CLfskIs7XlHcb0 4mGrVQRYj3HjCkGfXVDgm/Frw3NB8PnMW/6FfyyRN1+uUHgdkfXdmjZL6aejL9zG9TibvD5IQOmu rtExDKdqmqAtYUxbtGISszqcqLmlArHC7uKHMGZNewq4wK84K99qIiQbj3La9TS8DjJrrxeMoN+S hWadD2DLKY+YtM+Ro3Xo1rCp28Kf4+CHNjhu50rM4OCdbxzoS+gd6FYeO4pdCND2bb34bh8FZuqL 7ogpBnDvpF6d2nFDjsV/CZK9LQMNjjpdbnDrE3TdFrjHrQNZznq9+ndckrCONUDrvS0yzhl0mm7G 3lnUZd08L2HHl7UmY4580zMo74dHv/2cVSUDKicjpoKzHY8/YpU1Jt39NthM4UzD/+GQswU7ToNy 4LjpHTu0jlNf840MycIRCwHhjQo/z62GhL45nCoke1geR3F240/BWC13bPWih+VoMzs/RF6O0EDe +Rqrt3Hb2JgHA412ygs6X5dv/Kc6+utZNwV0F2RFCfVjKVNdS/MMxRxG7/BEE1LOR0bIs/jDiWeg SQTNbOCwpd39Ea8RtfI5xwLSz5sV6+uttcT+BHNCs3uVEPAGd4T5Guxrm4NFlosx9VvMKtDGIL+4 KPOor9XpVjxjHmM9cL1HDFDkTVbc4TfHivvWyL/fKa5VMSPb7gBXnPXz2b7rRDWkbBdXk9l90m2v AAbyV9gB64Wd5lsMqkxLYGtV5PJNuQG3RB3QfaMWsO9+I+R2xj0uqhLkOiiYf3vuphDUsZkomBvT pz2eaIINDhxdQ4sxKgsLWtB/vFCyhNU1g+7yisH6VcvTOmbR7WulmVZC8JDx4axh7K6E+nl/3cSA 3wdie1zG8Vi+nhyEADG6OZPXoAriNq9PAX8aLo/yHtwiOpxtmXATxrJHC8IcL96v/v6684ROlMja 51sdFwWXRG+c+oH5XnYhxjtbNFp/so8DP+1KjV6cvmri28C15tKB6NPZEPabWy64bDKLxaoIAwrc ijNEqnM+1bvhoMXHsdzI8rap1Go0Z/oVu0JDmE5CsBbKgliHzBhuijd853SfUIXGyBLOXATt/Fi8 UZTj2ZdlJS00H6YH6sNe2PeJNHXnHuvG42MRoxPsna2fX/sZoy3fuInohCUuDWXk2Jqt/XZFWaWH rFlqmtxDgtlH/5abaAA7+5ZH8btoqQNu7VM2NOf0otq5d/fPYOwNnDdA+lGGh2TiZkps9s+mfzSV mkzXqBx8NUdu2yf3i5Rhi4MH4uCN4S4b3s8Z3w20xK1DboYxCOz3lZ54vYa85Rb1d+djP/saGszm Y7QInv8BhECsjlocE4wGdBEvDKMLvzHflmX3dTO5VqXx3Kk5UAebaeYO3x1eG2cN6Bjn1XRioos7 cExZZQylI2OhJ5gLqbxJaLeYbGOmZl0/mCSI74WNv87UNrmHD3bNSzvOPDFb+jgqEnkrjs02MAbH dPq0DWbFJLION9vVbyx2CecsccDeh7vJI2EDQY6gCHcgTahEMuZpyDo6S8wC1Nm2kxszZMXumsHL aiScXTJhKk6zLr3ZpxJslbA+DjsDJnfhSADnY83v1HGrwbinz6IrW3ocbgYGTy82fOOusQJ+b9NJ L5tc8y0qCx0OifV/5t1RiP5XM7qWKHbBLnBYKf44hmW0MLuLBUjrpU47fOJdlmdrT0XOxw2xP5Z2 Qgz4EWwIjsEDMo4TLQPxLjjhKifNWZMwTWnc9L1FpybxgZznW79titOlnwaBhzOVnMF4SoSPGGEu LowxLbBCBEe5I87Gpmt9oSPfB+TjXLkTw/TPsSnpsQlW3uFoZkPOzgx1KPjMd4BVsQjBZaTD1TnH FKJT41z00+9E2k/mlayACCZhutMuHNBqhTbW0lmzYCLHfAgxynE3VGqOhi2W0LQlX7qJzpDw5aW6 As8wKi6Mt3BPBpJsr0Zzs0Y8Vl26+dDNbbjW5gz66cQIoCQmMbXPIqqhe3pEX4knlx/ZYMJRONMB qFwdc2Q75M5SN3yxyxBjdyaqnX3L4qTtXDKNGFLtzHlE5HOx4wccwzy5sgdnazOoiw/1noGjWQax I8bOeb0mVrkrXsjhDpAOe8nc3HUbM91J4qAhWw7ab4qOxXBPShb1FCuXsCm4GIhfeAwQRscQh3xL APGOyyYF00UDb20oEzz1Yzr1+zzgZvnvA020mc5hzOXZPYkRS4kB2/46w2W5wPRMt405r9t6Ma/X ftlqDwmM1Q7LYihx3eV+Bkynw4hsKI2/ukUHxNiHHQ3y+nNA6egMw5ZgMUjIdPSWe0dwSQmtKhal C9it+HmqC1eMNcBkG1Lz2ZX17GwNEzgLqNLGXw5y/2LiCzeV+S8OdkJfvtsPWkVId1D3M0xGofgO 31B0nykEkmpYS1B5Psc34JWqI4UyD4H4DEuabIJcrrtd8LIOuwItO+bm4GwnhnvdiuJheTc2Bu2L UPoPZP705JByGKqTYpxyZa/H7RkqVjYmC1LLEv5vK+gA4jdcaMPnej1kk0XP3/y4BTHfAe0Ec2PY jlUfY9vdfizAdk0ex/A6rMJqgebaSce6TgPnQBp3SAKRjouGoJbNtZ5cKojecory3eAEQGYYv+/i HieX8p4YEYyn6/ScuGJMxEG3DqHK9sfjcO7eDRfoWK9ijazD5wymvk/NGP+Zxy2vvc2XcdkMXCX9 D/DcXoaKvc7wsXqXbb6YWMezTScVgjKthnUn8bzpABuhgBRR/J+zRKTZNc1rc6rmMNC/dDuPIbTI ZurNcBBGBQejnXvWcZARZsLJt8uyYNj3kqkmbAWenEu6Yo5DQ5owEwIRSB6A3ch0RhiOxQtft+/w dbsmtBLoZtO6Peg2qwU8YJnGK+pNyX92GF5JcOduMErqGoA2XUqCOXMUfpe5maS+NkKnybtalv8A mgCVPMaj8rh/2T0xrnPAolkvXRDKLuM97621516c8nMnBYEmsJjQImcTWkwhMQEJ+NpoJBjgcxEs /zjyJ8WStrucjQ/ZeP2bAXInjPAr3fDEAOOX7+BbZPEX8b8OEnNvrj23to4WLJttj1bVQJW2pS/W WGK8hErDLhJbh7PbiEFRA9TpsPRmGZexFefqwChsOrGt/bj9wv80xMt/2I3sJMXsQuTh+jioPrhW xGisAbZpY437S1yXhparR8miyS7F3QUw/tkdZpQfiGk1MWbacfFILrjRhciO2ZjdMbOubEQ6Y3JQ 9LDEnTt3iSBfad2xg/2+u9Lkcw0CrmJ/ztzPHVWbTpqJAEKABY4mG9/hlotJBfyaSCn6LN9vw7CT h0Gvlk1s153yZebW8Rvm4dypC82DEuHezcM6pnAaf7JD2QlkBvLBMq4NxK6ZQbDkttXkojwHMX3Y iHc05+7Fb/fqRmp3tuvptOXV4sz0bn6gnGe6/CPYrvFY2Gh5JN+Rv9etrkaG3NTiCjCsMqTVVTgO eZnGQ4EjQOjlAD0rX91BCNIvWn7HgL7iz207cnMGpguxt5NdeKfPpg4g6wMx9olcLj1QAwWF5942 EAXt8nBI2zEvK7o8GVxjhxn8B5jsobhDxWlcSNlxghvndYuXwF4Xrw9s5h1swus4DKc6pkeaFC3L +KSgltS7McIWZl7vmOTZRtVeHh4owIlw2Ot8WBQ4gl2nqL0LyEpBH4azLGzyBKNYODtFmfFuBPMX MP3D7Vy6kwm+LWa3nfd8nKJs9a77bi1NwKOY1t9O6/mskEzAnttQcITamPEBxdIVvWpT5e/NcgSk 2KEnjrtWoSAv6XNlAygUS2ELlkVPd88sXDE4dgiGz9nfqcdcVLb7wak5hn5ut5jwzEHDxzCpa+o5 DWCB0eLGg/N/7Ei86OQO+dt3kYXjRx1pkl+zQ3cTYD19OcjvmAJ0aBdO1k3NqEPFexsb+eyjsITx 8H+C01dcCTU8AJeCO9NX1VvNYcwIrqlLfKZLkk5xZIplb2IMC9R8h53sADWEaCGru8kg/p/LT1tA lO5CME7i2CNdnZKHdPKybd1168nQrJ0T5tvtJX5gkY5IBg5/jupPd2+K8yoeDJqqBeoYd6PWwsKc Y+B82QVs9Tf2wRL1B6bjsDhMR7Bp32cEEznHDapqjM7ZKG4zDnsbAC9wDqew8kGOklwD/UDPrFOZ 201hozg4Y9sJDTm0g98hNhyu+yQPjCkUM9C3IqpaulSC+z1ctCTqTRbIINLo3YaQ2gttOMjZvsZP TvnsU3EDWTS30LfJiu4AXmc586DgttdZ/KAomcmLYcZlmJgzzHEXoI87xop7cvouLtp6fzfbfrqX O8vI9tbvTqcC/SbtO4TJqS8gLlhtcKGBo4Lc/APDsFE9uBHEnhtHGHFHWBTH7jrKcFvOW5zSASK2 Jso55/PJlpO97Y4pvlduvR3WOOIYMXOv0yvFhFg9pByNSs5Yi/PIjd38UhdfIrDuiKvddLW7j6Jv G/cHZwFbzc7ZHtHBFsNpPM7n4ys/SyhN66LFN78y7q6v8OsFd70ppMZuepd1f2Fx5wgZXNpmqjsK 0Q6p6nBlC7bg+XG7J+pzujzy5UZG54FjHDSM9UHQ8cR4jAVSOr6heW2toZOVUPw4jM/efmILWQ+/ 1UaG70PHgUrjLllaOMngpGwckr1EWKzt+tzo/D8sTXJggNPPtw0A6wHe3KC3QgChsCYNM4ny71u9 gwJ6lE2lxpRZnWybaof52RNr2cvJw/zYcAtOEhm5e8MDtWgt3H3LGYzFUblp2wZGW0tnhsg5iNdq A1DcGb1rj2+Jrhv2YBLJGPG7IeTYNreyx+oMxrRsT9g4DuDELWsuAETTsnVUyAKPcqPrtd/Oa6uz Hud9OKLSQun53pVp02S/heSIsvNwsOcmclB5CJLpBjj1azHjdj49R+k8vCPn2/V2LZrTxg0gT3ee oqMS58CzwHbMjjuDcCAOz8jZwnmj6Mt+IQed2+wF/UG4zjehZxpOqGQ2b1fv8Pao7cLCmrffjnqP Zi2WjWs+tdWdxQ6V/tzkN2JjU5P7xbccSn9+x0ObmPzcTOuoB6uSrE+3oPOsW3ntUJzuFLxqI9pd KWufIJ8oyVsW2cXPfMgW4PPeGPh2nIJmstOMKs53ZVfwusED6OUEUJ4GpLZtMXUb+819c2IH8z/t 87PdEmIjyX9AT05fcMMVID5qXV0zZ6lC4swvneeBXa3r/t1iEZXgTsOFt7Sk3kF+L97O5ahWEWB6 4DxpGNqyRMxWTM66YnrLxAla3OEAQ7cRRgsrLVuEfhUnnzlp91ZMwoJ9tnbXgt2Rva5msjmUI3ml Y68TVurdBOMBOV5jO0GtjruEGgYI2d32rBqBOvcv69cgK26qc/84IuUeTmRxu2/WUnCLlKdTALAp PB62xzuENr9X55cNtHsa/+cLlo1kkBkHOUP0rCdzCcZXLGQdbr01qYUKbUeRm0RzWgsyA0XZPO6Q 6mGCkjOty50bVtzYe1wg9U5rc3qrMqA72pELdLIx0EvyiURz/pqwBrwpPAKiaQEBb+DY1FwNo3uA WtbgXDlTT/z3Y7pSGrmclOho7M/pIBYG6G1wu4JgNzdBkjbnNUNd4ip30N7x6XYLmL0CH2GegFVO 8QBWualduIFy8tLljp718nBTDZi2HUNgZRagDcFNVtM43yVpoDow2kRYOX57SI72sGcFE1ddqenm rc9wG6TdbhMv1CPGi+EdTLAhw5iAbpmREd7b0qGl4poc0QXlQ2pv9t5SNieGnrudzkqRu+DLOsJn 26+GW/AU4Fko7yW2QLnlbJd3YDwPAmGInm91VoCz62FLpuEMcm7Lw4epwQm3XNdeoP9GjnAY50bF Ylu8o2t7tiGPL7uZo9h6ZKIBp20pn7NhUHd3iN1y3OyWG9TOeM/jNh1ARnT3AxSOjzo2FkNJHSxq uCa62TAt/aKsHUFaJi9upbKLDRP/wwvU6EC3dqcd9uXsQCcXNxf76MsBRcuW3J5BcOm2uQ3HdizE aOXuNq3QMMLwVywFttZCn19PqWu9p0PnuXRnUks9nBKHsDsmIN54UrHa0l5Wi/5dpnK4gfCiN1bo pktOHzuVN7dmJCxZrouZtHdnSbjTgnFwKBN6ZUUMBwY05D9xO47qGA5HHbe65RjlsLQaZxrxaRbz wzPVXtQAFNOOAUiQ/cRswm2LM7JwL45UvpU9DlrEweahCXP9K1b7RoXrRN0/hx596RYzFEcyDiNz d4fUbRU1DGxZeL583cGEl5BUZ7fOu/YTgTsaOvzx3ViCf3H4Y92OSVPjBB7Yjrt7ykmmFUPtLGlV xYlkdzj4r7482DRfClChLvgaynvn69u9geEFVQ+BF3oTHHC6HNyJBUOIKpIC5XFolnM9los679Lz 1d1qHx0micB8d4/ZRrCSLQiuNoNJmwB24K2l/RIgMI2jTiw7RV66RfHoBCdkX3+x4M1lja8RY+eg tOrUDedtwI8XhJXrijYYfcOFNq9za4CkndsQwAOxYOnOVcJ52R98F2jZROMmAYyv60MfAEFDD8QP ztt9Mt/Qgr2zD8TfhIeWXCjvzruz+2eHGK7g69YPm0GEPbw4pcdB2uBmAPmNG3dX2iXn0NxqUHBT 4QZdw9wVGtlgt9b4OKkO6eDCuEznbadozbnwdywnRBsaAp1Y/HcsskfpLUd1dKxZ9PfBnsY6rFX2 DAFOOF/rvM8xjHCa8w+tWDUTjRjHqnwfDAjiCzJ9hxPKXMjUoZDx+0q3Zxccd+0BWve6VaIWXK69 TxYNGAPo5vONsuh2nSttLA/cpgSggDZDN2QU7+UeIK7/M1DW3Bl6afR0Xcj1hd3+gwwSgTRZy1pk vwmudZIYVJ3WXo+ozXKohOMuEuQrTKcJ/8BvEaf2ZO17dGs37v4IHpx0lW9gsnAovBFHFO9qtozO 5qta7lXdjoOwW6tiQTljNNWFna6NG+av+itcdAamu0SXzTVc961DtAbEnLOJRct2q5tGmvNMDRhG a7Qt2MB5SD2O1taKEtAYVkpCn9ttdOdRnBiwtDsDHoXpwwDbjPt1S3s/jfl3ef5yuKtn0pJVbak4 29wclVPqnEe0rQTmPN0SDgNQodvrlrDpNAXw2GfxYLNZDfN+wldEfdW9sEg5iPpxqqhZagsfZGWm 03B9Jbsa57iIPP1WE4HgvZbGYzcr5mwQi3ZKuDQD6+54j9uTajYWLAXEsP/IlXrQ5pgd1+GaeUzc 62ZP7OzHBS03dJxbhwxBzMHxngZ8jhgQ32UxptsjXqO4KG0Fk8LK9uzOmeJlbnGbIZFgYudxeO0y Tn9HgzkJ2UVqoN0FbjnFtgSsNzIJTHHyXXfXSbJIEiJtKSseTl9vcqqYQTWZKK/tFuPCg2xfq4bv zA5j4FwvaZueQ4L2L/+KKY63a2U5OzZa9oA9N64X5Nqq/bFiwWYWs8wFhuvcI8NnrkV4PVOH2TkH b9jDWGp4l4DV7jmcybTstLiwTdDuqrzoziGb2byv48Sa/Fm7upq9pC5Z1J9Ph6E4TicZTgUf2//V /P4DeLspcWf5waGCH6pchnFHtMfbPo8TnrcgQxpxnJVqdabrnGVDFWd8bNR+ukgsu6XJULzlme67 fzVmw1Ci2eeTP1NwZhbAoq9zeqQ0FQANenGXWwMYgV6QNmxytLdg216KpoGTxWvnlkTxRdsu3VZs CQrDPy120w5njmCETAgAHbCgBkDcuOfWcVN+v93BuE/X6L7W6zU7JYHwrgxcd+eGw96XoP/237n3 Xqts9/Fp9oWDMyO/x1scGwfW7Uk3Xf4NN6y7OXy7WAlOGG3lfy3qBYfIg6bhtuM0WahLLLa1Aawd ooVG3d0TpeLgLeV3Wcit/Zs3Ye8sOne3FAkkvy2NDi6rbo4aQ7qf5RIzK+SPJevZDUuv6DzcpfKO cXeOMjrohG+w/KeYfP03TRDTxOm9+kJsvh0i1bXAb7wLNJ26ZHfmeeP9fe56uu3bkS1OOLHYPxST r44UQqvsssBZf9ZW31UM8jonH2Br5h3730+04tq8+rzF52eaFMKzfo65uP0Aw14wcEx2p73JHHMM 1rumi6Ws3I7GAMyaiPyNb7slzV40QP2wkc41Pu4OAdnFZhfiZ+VDM3bhsJv8mL9zxaODXDv+JSD6 F+QD//cwaJBwL7ZhBusyXVBqSd/Hf4CeZ052NyNTRaXFRrqZmgdab0ZwXMTn0ubvcY9isXnTdUMA hDeAb2J19C4v61IUHgJtmhaXiDKl3Xj5wlfZY5uT5Q4Gozg/28wdQuCSMMSPXyk8ZEKWUIkPwbPm OX530sS+NQT2iM072isi5xb3ONzruLbbXX3FnQ3qgvN53H/93UXHbrjB1uElbcuc13PZb4wqKxTW z+JDr/RD4YZbEQzgbLOuxfS9QOl4eE5HKC5qsVLTiIRy9rrlETTpChZTxbDr4441J//aaOUQQR7b xgkrhAyYusPlONVBSBQPQn23Q69+rawtwdgWHsAp0/zfbYmhC2UcdBVdo4c/5EcdJzeXda6+vlMo 1ijvem0Ly3d9hbsf9wl2KmkyojVscuzXLa5BcHV7Kaw24m+nCMmBqjbeu58F+uR6+RsmdA9g/F2M 7dXB4CbXNgBab+hD7csmLcRs/UkHhoqziQ4sem0bt9XBKZvOQwW3yF2cJn3+5qOV77Mb0C2nQb1F 1gVjy4lKspthwMdmZPBFs+oEGxrsgosigoqle9xbklRjxyrViiC6MOs3nYPbz+4x45gt5n4lBWqA M/KDB+3mIRvNXVzqQALk9EGqbLvcrdhJZI45OQfCgTrv3eI3Lp6bvxqCcGN8293kTp691svpVtbt uGTRMN27HJ7hoGa0BXaD7CNgRlcclehAn2T42y7qb98hb+WOFNnuFOBton3siFBr5c50KQB7bcbr Np4P9/U6KShD+Dm5aq+xHcdtcx3Wa76OIsVkISctg3zH7cJxeSTOWrIM0Z8WF++dgjPt3EmaHeXg Om0U0g7p6YD9wv8CwBbmqro21RQBfsVX3NYqBgfBoq5wcU4YmvQcvfVJVv/IOZQtXIXbDPcvv4hN NLpb3NyRHddYnr0cE+PQw/HaeqSZxS85sR7jE92MErGX1hyMGJ7gKnUT+nlparmbbtPRmaXYonOS 04esuViaCQtvndqMELiCITo2rnmn5S5dzEYRE5BuO2LG6Daqn10N7j6zkYsRbYf5mL5xG/pr299+ lEiMc3dAD37m5S/wE+65asOZvo9BFX7u24aq3FX76O23Ne82RA0nbXGmX7wT4eTmd05VBE+/Djo0 9GN7wR1q4uhLbLmrnoJz4Bx1sVo0spHu7kPH747y3HWC3cnKt8v0wcu6OtBmvwC1wB2/wdgirh9x 5katpncWRjW7YSNMVWnRYBe7c/Nuo8f8ib5td3DAorGwKEE2eOdZanZcClV4O2VrOR2r3OmI4Ilo 0u+OVLxbUmwLxzdYQLzENQZPHNLdwWcOqEFN7ADHgFpdNGSz4E5ri6YNtcsGKYUSF5VMZzQY2Rsf yG86brEE4E6ruI+zL3lR4fZywjP28yiDVnkLxpdZuJIcXGHgHxk9Tnw+epQZedl0F346fARZCZaO WJafqrOHZV4Lu/U4JcZKXQfXWZXw3Ii02cnPyIEAyF69ts2evK61DmaiYAZG4dO62Tz40AeN3HhO R+9HtdjhJng4YE/xr4uVwEF7VJ09ZSGNy2xslHr5IIc3PZjZz/olDMuy09GuZLD9Br87XcEWe8sg LI0ZLsdNyfpdXlkuBq2ynw+wxRPDv7D2j+EoTx3ydcRYLxzTlcl3HE086eGno4+KrYVyVeO368F/ 3X4YTLPrZRyHLAvD0jUH7VhbdldE2hT8GjfH9jh087GlN2G47SdCX8C1/UaWyq+K0H16BmaAYjaE OonXpJgwxZmcTphwvjf4FO7qsiIbjyZoo77b9LnNYx0d/m6vUPqMRHIdxZjmZ6eVKQ5E60x4su1T AAKgjtt4kkkGqb3tVuaCqyMxIwqFxW/JXJ7harf2cYJufoePiNTSzeC5rtilAshBt1zXTTvNW9ZW OSE5htuYB6LPd8NAtdZXeDuaYMfqA5HJ41xVhc794cXJWjVPFx1iYR0A4hoL1yGYQe+Wdzg0U1Sz 7Rlc9kv79QbNz2/wqL3Fz40wOeyF1xcfA4mn64g3/PIM1xykx/C8TVaWM9tG4uRhMCLHLLECb2ML LEN41R9HR0THjN3NXsXyKkCBW+jx99+zjRNgSDrM1zqz7jgUB6pYxmplmMOzTTik1wQzKK6FW6FU rBWAb8ETXxDYzdNYLMQvDTehCgfXdlCt004k1G7NjFaZJklrcHcVKNIdZI4QtvgDjG7YY93BAvBk iCaIaYftRCOZve2ieM/br+LUuuz0S2fguh7dfLjbOM7tA9vmUQ70ZhhexAg8TkP4sERoo1uArJeq 6coSB8Wz2VXKRwDBrP1+Fd2RLHwAMhskfUE3WKJlBYV71LDZBf4IYB+G6+HyK1mifgxOflYQYBJR 7u0EhYTLajwP54SVH9N8vwlyjM3dOcJ3dWdxifC5Fi3icmzPCtVNQW/9zV+ayRCRg6G7w1ubq36P IyIMwWZHUpkqq0Z+2m33fCViJve/DigxaukKhgMWA1zox0K1F3TKkB/1xMCZBv8Wx/E5XKTknfPC sUhquHP3VWISQETvOI5D8T+c5mJFgoBpu+fJ0NaM1qk4KCcA7GwjMkm0cdtGAIfP4tpC8CTvhyWy Ecc1Dkb68nayhLVW04keD2g2ihE/Z+K82HngoFtOXGWoXwcP35abu5vR6JgDOtR1BACDZyoqOJoa oLWzu0vHsKvXuLzz2urGlqFBNTkZJNufzLWVW5pV+q2BPKKnKdhKavmw3BsIWdyP5gSjz6LVypNi k6dVadZ8nlutpdbfOcjvLewAcbm1ZuFujRYglFyJdXRO+8om5B94oOV0n2Y4OL9y2+jAMzlyFo4H 0QfZWXlTjFOVWxCRimlVMLxJnbHv2lxXB9bpkiwn1mJRDEAlG9iGPxftP3bpqkEbxXfc2VTRqK1p t/0gtiABnjHyZJfd4c4xWaZIQM9D+ObyzeoQ16P8PHdOULUtmsNRMAqwyMz2c1vCB6jb2XYtOoXG ys/tkg8T9/Aqa0+dj5Fru9urex7bvGc/TnmzVqDjzGwNtZ1Ig/sZywNIPLcJO391boO2T7uGpWOH tYD4bztNUjWBvM1LvwALK8Zuji45yc2SXxsNHNVmf65dQpw1HI8fMiwA4kex4ZbbSfR3aMNCmEMw tWi48DHBCl6/6Ulw3nCoe5oOeHEskJtkeTa0mksFAaHLvY4RMMHF1DHI5LVKYzqAnVd1zHABpXz1 RtoXz8I9NLc6Oyp8OIO4WFVorsCoeXTIwasJDXvd3uiBshoO768Dv93F7ED0YNIOL+FD87AGJaJu AlMKZEFZwKEwRehy+cROrjG4FVTtztwZhnLwOwHKiVQhX5zmKrcwBzYJnHagXFy2BhQnTuMNbczh 3F1eD/xsoGrTf45oNwAAI3GOnyVHYMM5TG0BYOyDsDpOhPihzyg+AH/9CM+d+lqcliZ6aCU5h+IV hKbP1BDowrYN5whguc1qOJPe1JfVdy7fPAI2J3yvO0LHFUFvdgTVcAyWrU44iOawAiuYsI4WWtvS oPvqcOKE/ebDnTA83KyA97+bIF6hwBBXmJfN+JDiccXH8YpujbQn8bN3zPkvuJ7iaLPqbmMzVf1u z+MJ7krlx0hfudOB1jaXxPs4Bt2S+8lhvN2xHzZqNHPjpsGh3Q71/5Y1tdndsR/ss3eH/BdJn5PP QfmPn2iNOX64LPdMrIum3BWM5Z3btermyObdY2P4FCHm408V04HZcAB2S5tPfiG+fdyR4k55wOv6 4Kk3sGA2f/UCzvsdfQUcdCATjtFhRlxidV95NdBkrXuy/lrX6OKM025g3i6yLdFzduKdu6pzNbWi jZtbX7K947rz81kb9bqLCwSbXYIb7pDRmTNozuZqaGg5sYXjgC50zv3gxVF59rRy+i6Nf8pzG5Gc Ln3cjeNsc1wX/FguH02SNQcMOMSyOKLt7o6ez51K6bpgN1/idDF2LjWOqJuJO3RpueUOu3QrRLBw oTtBzykJ2UVDvA5MOmti8cD7uFEsWcX7uDQBa2o0a99kIWx2RBfqPu2mEIERIXTbRLir7iLqPZAI B5O+d5vxa742b5tuXpTsOGbfKqvmwF6hKrjNwJobaF6z+867d36picAORpk2o9nyZVqtWX/UbeIf zvL5eVbzeXA22K5LyZABBxqDkZsBZ4dciE9soIKtOoMJa+uSTTjqMKUjYdNjWbKHf+MNHp2AwXN8 Um3Kn0kSXeu6xcANPXJ0JA88lb08HufIOkXLmkiZtKFh01FGS/wl6JnbPUGG6xbnouifdauQx7tS 3UpfabDzj86Eudydiy5qtli0vlb9ugoMI5TM1hyn/Zf/o+lOsCTJYRyBXkm2S8ex9f5HSHx65My8 6a6qzAh3M4kESRCofeTPTgazz00PLXcmD4XOSkrelCmnk5qsXRP7d1dr4Y3mGqeKxJZeB8HUteGo IwkwI0HNy2Pu+D2o4/m3KUg1BA3eCacxwSRvZuP5ue1qnCIGn6IXT3EuRxA6qMhYnJ01EwiI8zrY VRl7Ssu2ExE9Fvm0T20tCbKD9og9f5i6+ufzWiOTAORrpyD+vnUFU6TQ+eI/+nxUcgma0SGztZHX /ziJB6k759jEIaiOYINa8/MKIPUztyJHM49VgzawZD9L4zYlycwneGuBcHkRuSCaFBx/MHvXmhBy EL2om0+/CSFvSvOEhptArN9Guxk+L4T8SUUYqobaaz6oZ888HLl6KxZmKiATdLB+pHFqiX47U5ms RfyHORJbyB6z3NqtcOw9DztV9LlqX+ZrLpRrsIWCtYJt4Jb8yPW15uq6LvkeY/CBfJhY5Xvxk7So ptDef53OnJqZGwExwLyTc6wTdV1cEWuWm+07QgqpuXoL7JjM+frFbSfAhirySRrq4Cw5pmbBwMht YeOXojtfht32Ra5UfCCdQ0nl8Hxd/m5PbNptLpLTcViMj88pP6ytNbkPIt0v+4gnSmkqxwDy3Y0j D8EPe1igXpZ8bTMDrKekv9w6ct961MTgkx2TuylWpOSipZx3zxDR9lvKglpkyJ3r0sBLYV4bYugN 63COIRzl158EfZ7dVuFHxyuYIB+XklMALWf2azrs3GIoBwV0I/pGL3482tSiykzc9NlR6nSN7lTm icWnDcRB52F6Ejdmqzc3AYdCH2twXB58w8/hAfoEuu4TlYDO4mDLbWPh2/NiZ+y9fIWL5uVYkwHP 2nZf9ZExBAIL8r1v3bf8fH9WFxxfs/1kmPfAQctMy13eJPlkl6Soj5KU4dmvVo8SvTu7rply15E7 cKY0WxJn8rgXBor6mfBdYHMe+bL73nOrDEfXHbWD9Vce802bZeocT5BacvGUP9Y+BjZtB8SqFF15 Ym/sQJ8jGDxQaTGTxYLrd3luXYOTWeqOZEz8ncQalr397rlAPUG88garzESUDyUn7x1bkLhJan0C fUEb00dX6c7n7UF8LdWAwc7Y20PAPygj57Gb1r52Di/8TU2WNltElSmu/NtmcW7W4kOWNnHklJag t+rr5gav559S9Zx7QUqRrliQ1Vdr/Sn1v4aYTHFCi5r7g4LibbSXD3ItiZ2WL2SOOyg4MI0CthXc /MaZOPb3cVZDHrMcm/RJfvuuPcsghlRZ200DdOLhmrcZcJGS3B/OBdqbUYdScnvLKqrbYLKDk0BH 07YtH58xmWwP1EqszosPKKQzf2On86ZdNJf4JO+po3My1JodAKKKASNOVOWpp7LVpJ9y2qiDh+zP bof9ZlQzxIS8caubif+lGquGqQfAkZFrk9/9UvTa9WZKz9rWVMAUMevqPzvNizUM1k6BSJ/te9F6 vlHo7xJBtk4eJHGYOlD643O00ElM3gJBzIc4r9gRLDYo+ayPrYx7++AHs6sONHdLN/6jJeDfHt4P P4JdNdhvhtUJH2PqZUKZV2Hlxp5wQttndXmjcUnydCEpmz8l7A6y63xT2WCu2iKrbpghiDX252H4 mahGveRouqlQd8CN3W7+3AmHnTZsAKVvZ44F5beLuXF+XZD7udyWQIxcUBC3TnzqSMxNxOTIqwOQ d5zy7KfGv/Pjvpdt1evd15yLZHcHd+f3h0Gdy5eSM/hZF57tH972mYu78QTZzM0pusy5oTkZCYWJ snkS6grO5gqFzywoYT8Pmp5I3nEO4Z1yuvc+aWcts+GupmuAB59G0n+k7nM3phyu7SqyRY41y7YT B9d7NBF4VS61rfKcOdfbTLAFzTmpiZBWMadMa5MML0Ysh6aRTSX88EFlJIEROgdAvr32bRLJNmQ+ DhiBb6XHquvP1i11QwqBlCEBjkg5lGtyW59844sj95ZnzoeuYntLUcd+ddjhzzHYU6yP2XdXWvbD SzamJO9HpXbyT0HzeTffrauTo2tlfsnP6tqSHMEWqAiXuJTyqXEW5fYnzHU8cwkE45DmvZNG6rfN E8NlSx0fUcuFxzr9JDK085cCcOSeWwE5cuPONQfwUeEZiQXMH+pF24w0r+dEqXNuObgXK6OE7MSb rYngbSbp23CN+6mrVrb0ux8cxE6ukDaCwJUwRlMvmGJ6ctW2+WQ8nxOkvH7zYSw+sabc6OO3Zt7S LKpNDOzzD08BiGTiXHuFeODbxyi87MD01PXUUroFLsnoU+q5Tm13YKoSJB55BYvOPxpcDn2KoJWR ItpCzoBdkon3U6qGHNnjS3pMfAvMZSOrWl7zT03Rndga7Je6h5ZCQP6Do6xzwIwzgX/eW+q/nfpr gnng2pBR816n7bZoPJ0aXqXVu+/kdlMezerYj2gjLY9gy/yVVOloq1uRaR9Kno0d3rqQXsidQ5x9 U7USwg7IGNiEO+5uJ6gfDPucBxej/a7pAVZWs+1qarn12tFiuJUieuS1Gz+99P4CTFNWfXgWC4rN 1yZkh8X2DFG1IGQZ9MTn1ibbyUnpn92IPfmkeUWpvduprH1yZ3JZr9/mS8fCxCDjq/CWjNKVAiOl 3oMQzgviKWdfVii5BqtHRWN0vreSjWXWPD3zvuqOWpPjgRPoWOINSdF+RmBEPm0rEQG9j/wYff5E ne2k6uhUJ0SX/QsfLsoRfWaB9lGCaLWPRn4tsXhnMTK5vzPL1dO2b9ILFkAu5XETz6XpyQQ3dehA 6j+1OCho3hy6k4+gMzsUpW5gvC1TM1Efecu0MQj3b/OSpzovs7z3uK2J4UmUrbVU4skSQZsaUwko jSZlK2rsTa3X+Hu1KTUtLMDPau0PCY+T9NQJB+c0aTFaVzkGbfWBgHGdwSDJkwaCyZLmR3ldHcE6 lWvO65QilhYN9m0yP4tXYi4znbF5Zx8/JyCIRdPajD7WNYH4ThBOwpnnYHHg6cZSe5ol0CnVsAbV fhBnDJpuZSjzjdJSDNAN/EeeaBo3jVnxMZXZUP7reW104TuHZj4kBDFvxIwr/2C7VlY47DM7CrZR j6PmodunlVcijxpHOi3vLie/T8sxGivbiAWqXQ+iQCmIbhokStKt3N6eHIuUBnaQy5WeFAvK0V27 wnqAmp+oj35znksAZio2q/ZUDJLo7bPuO3cSVlSptL+5hmQTI8kt9RQTrmQvjNkAwsWGG4BxaZqs TeGvq6c1OjnNYiEZpn21olHmQyxpjudZuA8EEm0ncQ5S/0+q+v1gGmb3/SGROIhAzHQwrFrlp642 LZ/JBvykeU25MGUtjmM/SuM4uSexwq7ky7nvUtr65bPlJC1l/Z2UgikyFhZmRW9N4NjsSJo6WJHm BjOxEkPT11tjgmXukOyHnoJFmEStdRo4pj84ym6SM15e5IRRdPixRGfW5ys2RMf0HZTNBt9T/5ei PZsEy4bbQhhv1KB7571LZGtF3g2eDCQgk8uK4pzeRpl/JUmPI13yZ7mJB3v0xJWPXLZ1R7oP/Sw1 CM44AaP4hIEuV3nX7e1AJd3ZU5uzWm5tNs8w1Y7k404/ZLEf0lti72tDVFf1nbH5n1Qvm0ld8KSS a9QW4qsWsqaTR9tEzYteCCPuROUUq3hPJ1F4Ji63bvp+Tdf+JmkUUnp3y5KzhaOXzjN21MdEXtWJ hJajurf55oTHa8cvSlLYGQYTsWhMJFv+VsMh2299I37eTy3JJAn3ZQrAlekbxe+8rQCNVKIbx4dE 5lyPz2qZBlES/kUCYeKVyHkwAeleYYxGzJe/BfV7pklUyo8Ces1CitO895QH+v97Lr4oxuLEDuQ6 JfrSJ+jMJzvDTUrbeQZkGdYVPOvu/MHXwfYkS63kS3zgwNtN55OoVxCrQfiXfB4ovl2UI0g1GPRc KwGMy+VI4thLXWaf/PFOqc5i+vOW+0B7i47fjJSWVKs7qScspxQXn8Hsrrfyyf0BaxTZU3KbIyh3 25NiSG3X1i9BebEykt8fLDoT76J3nBeQj9q+Wg7NF+Ssde8bp8r8iKTV6USIxk3qtWqUSJyip8kX sx55531NjXtNxRiMm7u1l5WpMX/OG7fnwIVbQU0/xRNL9AlkMrSEhket0qdGCkqmC2fLMBXtGMVN nubTHuZx5+/enwV8X2EKiEXEcR5eOrG8kITNk5aUmcP7E/7irVVi3Xu5BQfm73qqg2V4BebkqvEA tWNNqbSSZyBnmtohkT4X8uFxRT5yLvdxDMVvT20cpJd0GuhEIvRcupnAxUjHSGa+iTGxXrYZHcAK Tn0kHVPLmgiuSF3khvMu+Ks96xqoH9zPYihhkpl90BgbxvMpZZChXXJ4XRfLMoXaueEk2qY+1iXZ MFcNAzQpiNJluTCAi7kqk12btVmU6jfedlJ94MVFfgPjNygpRzHQ1KnpSKivPTFkRLvs6OaG8wHo qe+RBS6/wCZT3lEye54CMVUiKARGbu4/uXiqKA5wyOhTLevtnewbxgfZ8FRMWhvlcjocgZPhLLFp 82ihY9ny26zmd7qcnpdtz6Ee4WoIOxSfO/F0XJrBy5QiN/jVRp/dmvzqxOkJAYTlHTMG7EQGzAee RxLRhwqWLxAQlk/PgflkTnnd7uwfqLzZB6YoMnNvPBv1Hgi1PvbZ1hpsiJ3IukQE+FPeODX45S/m WO7LYbMyF3hjtmphaUZUTqXSO6vX9XxJTnM/aDlbiUWDheng68lrJOc9l2ZaFjqahuNmPBMyBlVS sTkwNO/8OvBi15up03juqiETa9kjpaZK+bQpSbBpboKOZyApF9jnorDCa/JKGrhKf+ZD3pI+N7IZ KqEcmjy9KYnj+eAvsjkHOdnLnIGckwI/1+d6+UgtLMzU6ymqGFJ/JcGeRGG/K1E2sWyj73/tCPMs ep988eRpM+hX8k3hcbyWQdEBg992XUVcmoPhHQWoo+nZPaSjdxoHnZgoLwlOBdepFPRQk2Hw+CiW p6QoGW9t2IvA0MyfJGVAHumZ053AmzifE7jVqCwBSdC4cbG3ku1imxv4zBx0R5siX0LWSYMwBZL5 WSBzUPyrD8sPzEzqox639SsJjmjCuY+b0Rka2IySEjBPJQE+XlKp5x6z8qpOUipUtvI8mY8ggvZj 55JFS3rWWBjk9zEgbXV9K4icsnwk5SyNtY36Smf2s+3V2DDfC0GFjn2se5acPUoRq898BEmd6lBv G2MqjNLAxEGJwPLixDiSrQ4Vr7zyQdGXFK3WaH5HkuTKvYOCYEr6FDoTNlLQ+/IGkhya/fR4pzpn tHGnVsadxD11FvuuqYH0wJB9NmZ58rmeM68+kTSx8SvuKgWRj+8q/JzLM1v9Up2NXurK65qQXXu4 yVT9pL+5l/Azk8c81pxU45ZOtnVOkrfN0WGIVGV9XafFANc3eR6sljyU/EnLuLcFAYk370Nr22JW KvkUg41zAnmj5Krc0R4cWsI4s6o8T7+8MZL/z620qjaSC43f+leEVJbyqcaDJXMMNAnyxPv+QOxN BcJQCTn1TJ2bc57bi66ktrl4f2L8EKa5zw79B8cRGw/gppF4Mp/bnTe8lYnOcZ7QyOe10m4DNmE4 gbSUgPvEgWFl1F0KSyzY8sTzPltptD7575YZ9yQS6e1eA7jIIPfAGuGXUXNdEOy2EpfHt27fvFOf vpXiqDz5LpTDF5QQnkO0JNaHlP2e1xsUnAOz2qAdU+uDYG3Cue2+cXeCPqRdeWFpKi4cv1iQ2P+4 UdfyE5J4gliWnbhAMOnNzo/ewVQ+zpMW183MfbV6b/G+XfizCQfJC8uw1OUKXvmfQYeB5og8WBr2 qipdGqt8e0m894WVPQx3HExMho4U6bO3mikJ3hXHSZwGGuSo5PEeeVcBrmYanY+Intf10tlWNKz5 9dgNNPlv9frBAWhdWqJdklOqqykZKMFqCkhXrwTuJ6ReBEUDaxZkp28jiJSX8rOVp7yZIn+vD18V ++eWXS3BCGjrzGfyr+2iEupeRxmDbxxnHilqPspbLuHn3o2UTyIoT3J0S0W+Bq8lUGirfjoJeVfa FKoRojKCcAJXoERLtb3WfgMunxeTtzHnATHusVCUkMGkTF+oOuc5ovnWSdk+Zt6a73SQ50hBnxuQ Kjy3+tb2IiRMh/L4jtTW55Sf5xK9cmNAATmkPU+pBHkCXi1c50jkVYwiciRWBsnk0TCfuXozwPYi jkXLLg/rY/318WZTJwuuA8okX5doadegC1ikjV6WP5qVM33yhHSyHkzNAD1rbu+3YQOxvsqB0uI6 Z+OlvGT8zIvk6kExmQteSghunTYDgxLEpXziCf1sFw2o/iWq3iXlYShMQXMpHWdEkkO5/+FvjRd7 K0VOslJjIlQe0QGueRQ5aTfthnW3y3qfeR4pvic0aOyZe82vCjhLlE4s5tc5MTpAL03t0RjQECLq wW49UYYQ6PocLc+E6LCdNdoT55La2cJ/MFF1TBu389YvrAQ8g7G2htOUU8op0Tue7LSeWgI7ks5B 1Wu1ix1gxuqZDEsyDx2A39z1xAueuTclbO6Gl0wMlsKXpDB2ptB0IREzErr40NeWKNPXXtU31dfd puV8lmx/E+Suttc4arGGNidirxT7NmaiKRTz5LhyHf5kjm8C+VK+2xdBQZY9U/K8AftC1yH1Ra0s jrdM2nS+c9VSat45DQE43XIHVyw2nBwjbInP7Euv2R7X/haThIzumFMwzZIZw+mLacRrtY1j+obW PF1PYgZNucA2qhAplFf+nsmcu4if72tWac5HC9IuvE1PG5UTeUZGC99ST5ozXJLKnYAiEXKULkby HrBCOQLmxDRIiAOwArzVyAnfL1CXotfEQA95IgU067YmIvSfAWeKAEzDZbfVhQ9Afj3Rg6DFxkRY 5ZfAjylvbPHlzd/LnERs+jfzv8m99FV4aSQMBwQ34ZYG3aNzx2AvH8iH2ul0JrssDEuwUS9mjcnF OJcnzqDtmxSKc34ZITNSY9MsuBPVnvOihr3ys4ydzdE03/pLBSDoDxBcUtMT1RuEgFvJcNF2mbmU sv0TI4k/UnYM3tpopCeD5GJdrCinK3l/MiXrfAyqGRbYz9OD6s/SWv5N6wxdFnYgc413fWFLHhoN yRMzDcEvzzXHCNMmlZ9Ky4RNmt4aM5WNjWjC0Q3Ynwh9BM+YL5ZjswxyqdzQafMXO+Wlhf9Igrsy 8+zFYrDYGTyDSmrPW+XC6i/PNbkiwdgCaCrXgAvTw+kZ5bBkMZ+7XcqEyfhqoasN/nNRT8SwW5Vs vp2lbJeqM3/eWV+CQBVuCSapi/P1njKzzMXgHf7wipttDh5vEOuycr7N5zSd7kfpxiUZkZorPc3r J2L8qN0264f3wbc7UX6/c2RSlydB7Iwr8s+JZ8fu9qRiwk1fU5+liDsoNiRpBkKQE03WSthJ7Qvy /AE/5WTg1Eb4ZhKrwdoAvMVW7LxqKA6/NrXFo6ALfgjQWOxP5tFoN0/vvedyb0fgLUUbqpofOdOr BV2Q+MGqePN+xwM5HcyKcQ4m3sT7QFVcxqj6fZGFy+iQ/vZVDgeE6QPDJ9eoAecYKDvBx8tngqKq eM8VSOn32dfD5qWszZHXbzHq9/mIN1nwSL6wSd0D3HI5culPHrBbIgQFCEpBSUPnl2KMCkbPfcZn 1wx/N7sNV7LKPQUdXD3FaCI7aHPlQaTYTD6lt/EkTGBilnTdnAN3JWXk9JCpTyGwP4WAjT1X/LI5 ECnVRsrGJfcsR9UuSE+NPAgubAnbb9Bs/iMBhA30OKd8vwnN5aANT+kkny2p4oM77I62L5e+kYBJ OWdlOFX5Rc3XFnailFX9PVk5hViilNTDjpbt0kPxL8nDHCRQY0ZfaTi6o0bRHwuaVCfat2dNa7jx JD6zeJi5Gy2BdoEPL4WRJLCAtTz313TFVwkCzNc6WxCiDlRlHGv9DLXHRrPuRS+vWzl1uy7XqOVX S5sLvW1Bc07AnU3ybGdtLxXmhCcJMRCZoOOka2cYfpndB8WkJJeJaVTbKwvCmpaDev+e6ja/Kym5 HYsl5oZzH6CdDDqhLT82ao/FXitpMx6NGLswab7SnPCUcOqc9QWHXCyw5o6VFdB62i050HTGYKpJ a9P4P5BShZ23R242gONO2Kfr3wweW35N7k3QnQ+1ftqGTwINLcOEJ8yzrWwt51JcyVV+LxadufRH sumnPeYIHijQl9RQhna5CM1eNfEDyvTqF+Jm78KnaP9S/+6Eil9aS7hJB6NSxqj56QHYBEfkycuE OgG1JxJg3rPnECFyGaSBZc0B6GVKk4tiKTmlRTeuz30cvNH2Zk3jDpLhEMHzGGArtxddkED2pJtU 809RkUtvhTDBqnF/47xzY53zJXnjkOgcFmwOtLp872LgLfYF1wIRhowYgvuP8VPGrCJHkg7PDH0W iUMj+qoqJyEOXcFG4mOv307HpBfbOgMWVfhRxValB0Qn+gQ2OLalNL/ym+eE21wKzy2voCTBGEJ8 jKRtgfAnSLxAk9EeTBRK+ZzfuOTx8I2CNxLcv3d5xLLzrN3aepJNX62hZ+ZX5VT1Lknlz7gbqThf zIc3+DnxIxUZnfS+B+iCuwt6UKpkEq689PaXoEbiV55PuzhqctXYFs2KQOQyY51zZG+bJwRUGnl+ 29+N1sU84+7jx1LKzytIWi1CR9ICBw+7kkefrO7rpplbGyAn6rSd7NZEX73RYn3ylGrjz0Vd862v hdFfEkFOqyxi6rJRkkr4SPzQys8xobSo9W0ZrJpsQagGbHYD9+Sbk9VosSFugkeTxGyRCrGHtDFd AcqKzRz2YUMlwcAiN5/xJCCEL829RneFSncgGqkIOr4aRE+epHUwKu6Jv947PHQ/raY9iaDgcb56 csRj/RCKT0nAcCZRZiQn3hSlrFzmaTU043MXAsfiH9+TTadp/XTbcCKvF4yHIa/DkbBrDZN0pHYK UTmKWivjSw6mJQTx9bI2ps1u3zcV0cQvIJ/W3dyafW0DW+aQ7JTfFFKIRoF1em9513j5vBl3W9FY bmRqidIQJEi4SXT4njnF08zZJYVGDmzSLxmu/PdUhr8O/XLNHGzzDpJsU8WW48zJ6uJOlE2pfb52 d6w8Bu0F8eaRHVT6XxomqW0WmrHzFahx0FBJRukLcLngnb2O0mMNMdfjoklHMoRNL/mKxCfbZkZX qSEfMmM582hXN82UMbFT2uytmXitfM+V4l3VM5nkHqD7V0p0+71dNb5iWQexvYq1eQ/+Gqf7WN/d Um/eoHbOlwp/sRQ4uFEGSODsTQjbN+M+MhUJIKkntqQmXdMJsIKv7RQGhrS3PysvKD4K3I4Ifb7r YamHz+NHkvmkZYFE4Rm9M02alUcdfbC8+bzbwMFdnWKjOvh/n/NQKMlzoQoomDWkyjWWj24KkWPW vyePs5bL5FIORi7Mw72JExOIUByVrlA9cxePpEfS54g5D53481HosTlbprvG1yn6VlO/i9nXdYEU WMA5UV7q13UrORKm+tz2KuLPxPXvLIYK6hPywGzlU2Pio8yWjEJDjfgFY++9KEuzlZPXAoBbQil7 cD3OHWhtD9Q1SHdox2/hHaVxJrW8J4fAMQGDhJdSve/6aQPvE8XgoDI37g2p8mU1hR4In7IzPvJK jgL5eNApzfrdrK1P33yydKaEORnPpMgYpNqoxQaWXgq0obVjj1b4ObknPx+La8KbDeeBosLtY7Qk I3zxnKIctFd2TaS4k8CCboMqUYOpJC68dSlYTXyKefhRLsgjuA6O9jxVOfMcCK+dkeZ3bTru+j9b p9Wf55EDObaPE0YiDaXQRqqaJfQILjHEYDV1WThEIJ7tYyN2u8BTihXi6onoqcBSfn28Ib6yh0Ey SwyYN6Oc/MelDOzO7bcYz14mccKiBrpeEn6+cv7EBavmJV9GC5+RUN7cHCC12SzTmkjJPV2OUC4P /+4k5bZUnZ1/IQ+RPrdPs6u7za2XFLzrWTx2lN08poQFDrtbKrOtxHw7eo+JXcqEkVuYQPEFteYX K46pNlpOyRPMO+32wIylX95neN8p2EjozDx8UeM30oLNVnpeW7743q1X8v81x0olhp2BQ/HSGrxA Frj1ucp06Gv2LVL5EGiwJ7xYnFY2JnbpiLy2B4Kg2UYCjiYfy0OJ6Vz1FhPcdKcni1/LTJltdGOb ZzLTgM6DexJj3nOz8nAjcw26ZJzbbgBet/a0F/OhI6dUfIlQO4fUVBbYmjvbNp8UdQMBcy4t4uU/ kP6xOPUOcjriEHC5p3zLvf3dqb0GT7yBn6J8EB9q4pwZO483pgImx3vNDPZUvySEd0Yt6J2peNSb yII4CfmP5+saa4I87G6T2ujaTDaQDgYRKWsnlr3PKL0563I6kOq5QDJzrYRGNKLnwtvpZJF0k7QP mMj22/QnyHC1vlF6F4kM2PDl5JGYlW9FrHcxWLOinUAxfNJVg7c2zRNiTQtyRc6EILtUew71hwOF /ZYYZP3yJ9QVqL6Y0VP0+2jFXCiA+S55u3nuuydoueluLeXLfZ8TT0ctxNzj3H1oPJ+2J70zdiZt asPUWl558iQIJkdS9FM7Jir2t1SGkciqa7E+QjJ30uCPfOX+cunmfbXZS7omrnNoupygU/k/6jlC vVdujQ3b/CEH9aRXo3eeN5z3jZadc3fz0i3OtC2EVOlJG6998GLxKvZXvnl+72B2tJXv9ZLKML9U JzyhldIsUhYphrMiMq3NT0pu1oeSaYayIT95qxplsq5vOzoQGwNwBO0sNhUT7HO08+vGVCN9lbq+ F8X5/DeCBbnGP4G4nP67jFtvBNKrZtYYSte4tmm+b8ZGOw7apggNbp92HncrcsMwAdxTDhlzJJ/z fsHbDwCw1nfeKcT5Y/HMTJbPnUpF9KU0PyilJbRMuVvja5LIQjICYYVYT+rVrS5RrkE+72vu+CL4 T+UH8RDzaaeLv9O6L3G9rZVQwZxHdVh9D7jYZ0qX8+RedC3NYBY96XyXrrWS+jkPJTet0Ty5A7dI LTkMN4MMchI5IqdlphQP3Hn3RcNO0bPPOeJXDkTOAffND3TeCDUOSUrQzHfmU4UdiE7Z9SAnyr8r S7L+ulQY/ZN+bHnYWFvcLKjnRdqismxTsuT7ooH95YXtrZe2K6u5z5jLnBa9Juk3eDUBMUmEZ4lu k4ES491iZqf8SB5cKCIH6iTd5sJvN2fMfNFcds4+E9G8HNLJ/C1w2H+lN/chROaPITfSRqrjxSrr Vdb6gjv6bIJnUPfgpnXK6xvpIEvU+dyYw0/P3c39M3NuBxYwx+HvtPGZ+oYdPFuh4Jt+TwtBKx7W eb5Kl8B0Xe1z5R+gS8STrzH2zJFMHOYGj8MmB7TkmlmJtiTBrrJlbga5OWI9cxVNwmngf0AsJ76H hgBzNgzCmxIoEaf1ngPRLVkcBDp1EwmS02wIuk/yTDWKdp24sey1zd0L7jqHKeIQ4Gio8Di415H8 wxlbQcjZcbP+FqTHL3bCLxJNNpJPNGu/baI2ONNQNaL6+qHkgtYr3MxfibokT25o0phG71wM2LJM PhDX31Fap6nuno3jwI1PcOysToOybTRfbJD7b2aaUiNpDV4/zGaSfZeGbUOEscYXxFo3ToiJkgs2 B3eTEdi1r6dI59tyY4XEULCCO5NgWTkgfqb8ShFB/Wb5sfM7/xVUpkS3HPaHYP83Nwvr3HhStxtA c/glaJl0n3Bwft+kq3Y2noe672cCh/2bj8dOvuVFipHyb35GIx13WVe/S3zvQxxPpc0BOZFxBcc4 8uZu7x/XkWDU4xJrmU1q5tv/rfWVPEp+fsl5uzV8lIMnhelJFzLId9izSgSkXkPqnWpO6ruXblyK HFPqZwuQy8cNHtyfvOqEXuE4d+35Hqz5jZZc8Dozjm9VaKaowxOzBJ1qgnumK8JRba7xWOrE2rbI ZwhoT7zVoqJxkBeKAgnguEf7zlPVkKEBCwia3zISKObg