Question Set 5 What are the issues with data vs. document style xml documents for persistence in a database? How does middleware fit in? Data-centric documents are documents that use XML as a data transport and are designed for machine consumption. Document-centric documents are designed for human consumption. Theses type of document are less regular in structure, larger grained data, and lots of mixed content. The order in which sibling elements and PCDATA occurs is almost always significant. Given the lack of structure with document-centric this make it harder to have a well strutted target for processing. Also, middleware assists in the implication of either data-centric or document-centric given that both are stored in a traditional database. How is locking variously implemented in xml native databases? What are the issues for performance? Locking is implemented either by Document-Level Locking or Node-Level Locking. Document-level locking occurs at the document level. This locks the document for editing allow only one user to edit said document. Document-level locking is unlikely to cause concurrency problems given the unlikely hood of two user updating the document at the sometime. Node-Level locking a specced node in a document. This is facilitated by locking its parent thus going back to the root. If the transaction does not acquire locks on the ancestors of the leaf node, another transaction can delete an ancestor of the leaf node, in turn deleting the leaf node. How are the nosql and xml database toolchains at odds? How compatible? XML tends to be surrounded by complicated tool-chains and processing rules. The NoSQL JSON format is a simple data serialization that is less verbose than XML. The new data serialization movement of JSON, it is its simplicity – the schema-less, dynamic programming, JavaScript compatibility nature of the data model. From a data structure perspective, it has made our company far more productive and focused than we ever were when using XML. So much so that JSON is now replacing back-end services where we had traditionally used XML. Why is XRX claimed to have simpler application development? Give a particular example not from the reading. XRX uses a single model for data (XML) it avoids the translation complexity of other architectures. The simplicity and elegance of XRX allows developers to focus on other value-added features of web application development and enables non-programmers to create a rich web interaction experience without the need to use procedural programming languages. To support this, XRX would be very useful in Real Estate management. REM is very structured overall. XRX would be very easy and quick. I support the Lockheed Martin Real Estate team and after using Exist-db this would be much easier to store and retread data. Describe the IHE from the reading. Give special attention to XProc and transaction issues. In general, IHE is a consortium that develops standards for health care systems. This consortium has the reach to publish standards on the communication and design of devices. To assist in the communication of between consumers and suppliers a Cross-Enterprise Document Sharing (XDS) repository was created. This resposity can store patient records and even x-rays, Ct scans, and other imagery. To help facility this, IHE standardized a high-level programming language in which XML processing steps are wired together in such a way that the outputs of one step are routed to the inputs of another step; all content flowing between steps is XML called XProc. Why is xml technology good for specific application areas but falling into less use in the general web application area? XRX gives developers the luxury of using the same data selection language xpath on both the client and server. The same expressions can be used in your MVC bind on the client and in Schematron data validation rules on the server. This however, is not the motivation for migrating to XRX. Declarative techniques that use XML structures tend to accelerate the creation of domain-specific languages. DSLs are easier to manage with forms and graphical user interfaces which makes them more useable by SME’s and BA’s. XRX is the front runner in the declarative revolution and the forces empowering non-programmers. Desribe the typical modern xml support in the database postgresql? When is it good to use these extensions and when is a BLOB just as good (give examples)? Postgresql supports a XML Data Type and Support Functions. The data type support features input checking and support functions to make it useful. Postgres also supports SQL specifies the following function-like expressions for the xml data type xmlcomment, xmlconcat, xmlelement, exlforest, xmlli, xmlroot, xmllagg. One can used these extensions with working with xml data that does not make sense converting to fit with in a ER model. A BLOB is just a collegian of binary information stored in a relational model. Its might be a low tech but storying xml in a blog would not be wrong. For example, if you need to store order information for archival purposes, then a just a blog would be appropriate. The only down side would be the limited nature to analyze this document among other of the same kind.