November 3, 2014

I thought I’d write a really quick post because again, I’ve got an error that has zero hits in google. I’ve been working on wrapping a web page around a web service call to the http://www.business.gov.au and when I deploy to IIS I get “Error:Unknown KeyStore exception [4699].” The USI stands for Unique Student Identifier and is a new government initiative requiring all students (tertiary or otherwise) to have a unique identifier. The common feature is I guess whether or not there is any government funding relevant to the course, not specifically whether a person is a student or not.
Anyways the answer seems to be that the keystore.xml file needs to have the read-only attribute removed. Additionally the IUSR user needs to have sufficient rights so as to be able to write to the file. I’m not really getting why this file needs to be modified as, as far as I am aware it contains the private key proving that the company is who it says it is.
For more information on this overall project see the links below;

Information for developers of web services integrating with the USI Registry System
Training organisations required to report under the Total VET Reporting Initiative and using a Student Management System (SMS) will need to ensure their system is enabled to comply with:
The Australian Vocational Education and Training Management Information Statistical Standards (AVETMISS) 7.0, which includes the USI data field
The Student Identifiers Act 2014. Under the SI Act, training organisations are required to record a USI number in the training records for their students and verify against the USI Registry System that the USI they have recorded for a student is the correct USI for that student.

Note this instance validates fine in XmlSpy 2005 – yes, I know; not entirely trustworthy.
Stop press – I get the same error in Liquid Xml 2009 (community edition) – I guess XmlSpy is incorrect.
Interesting though – the error text is exactly the same; does this mean Liquid Xml is using the DotNet validator, or even written in DotNet?!!
Surely someone else in the world has had this error…

For those of you familiar with HL7 – you have my commiserations :), yes my starting point was one of CDA’s complex types.

Thought I’d do some more investigation – Liquid Xml gives an error on the line
<xs:attribute name="displayable" use="prohibited"/>

so I’ve removed it and the schemas validate ok (or seems to – still has an error listed?)
Next step; choose create xml instance and it auto-generates an instance as per below:
<?xml version="1.0" encoding="utf-8"?>
<!-- Created with Liquid XML Studio - FREE Community Edition 7.1.1.1206 (http://www.liquid-technologies.com) -->
<data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="C:\Inetpub\wwwroot\XmlEdit\SamplesFinal\HL7\testDerived.xsd" xsi:type="POCD_MT000040.InfrastructureRoot.typeId_TEST_P" root="2.16.840.1.113883.1.3" extension="string">
<elemA>string</elemA>
</data>

Alas, still invalid… So I guess I can’t trust Liquid Xml either!! 😦
Also unsure why it has decided to use the type POCD_MT000040.InfrastructureRoot.typeId_TEST_P; maybe because it was the first derived one encountered?
Swapped POCD_MT000040.InfrastructureRoot.typeId_TEST_P with POCD_MT000040.InfrastructureRoot.typeId_TEST and instance below now includes the last type!
<?xml version="1.0" encoding="utf-8"?>
<!-- Created with Liquid XML Studio - FREE Community Edition 7.1.1.1206 (http://www.liquid-technologies.com) -->
<data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="C:\Inetpub\wwwroot\XmlEdit\SamplesFinal\HL7\testDerived.xsd" xsi:type="POCD_MT000040.InfrastructureRoot.typeId_TEST_4" newTwo="string" newOne="string" root="2.16.840.1.113883.1.3" extension="string">
<elemA>string</elemA>
</data>

Unsure what it’s doing here. Still invalid though.
Schema is still giving a error (although nothing underlined and still generates an instance – shouldn’t generate xml if xsd is screwed?)
Nothing for it; strip it down and add each bit one at a time.
Summary – added each derivation singly and is now OK! NOTHING HAS CHANGED – maybe a caching issue with LiquidXml??
This appears to be the case as the removal of the “prohibited” line is literally the only difference…

May 6, 2009

XmlEdit is a web-based application that takes an Xml Schema file(s) and optionally a well-formed (of course!) and schema-valid xml instance and automatically renders a perfectly functional and usable html graphical user interface; that is it automatically creates a web application using the schema as the template and the xml instance as the data.
Given that Xml Schema is the pre-eminent templating mechanism behind xml files, and xml files are already the dominant accepted mechanism for exchanging data between different parties, that there is a niche that can be filled by this type of application seems to me to be self-evident.
The niche that this application is specifically targetted at is those suppliers who wish to engage in internet commerce (ie exchanging data via the net in xml form) that do not have the IT department available to support the extensive development that is a pre-requisite for this activity. Indeed it is quite possible that this solution is competent enough to rival even those that do.
This solution gives any user the advantage of agility. As back-end systems are inevitably tied to both a database and application code any change to a schema by a supplier will often require substantial modifications. By using XmlEdit no modfications would be required; the interface would adjust to the changed schema allowing a companies users to add and edit information uninterrputed.

Point of differentiation

There are other solutions of a similar nature. Principal amongst these is Microsoft Office’s InfoPath. Similar to XmlEdit its primary focus is on data entry. However whilst XmlEdit is code-free InfoPath requires a substantial amount of coding to get a usable form, especially with a schema of any complexity and some it just cannot handle at all. It is designed for relatively simple schemas in mind, not the often quite complicated schemas that seem to be a feature of B2B commerce. However by far the biggest difference between XmlEdit and any other automatic xml form generator on the market is the XmlEdit’s ability to load an instance document in the right places. To the best of my knowledge no other application even attempts this or, if it does it is as part of a customised schema-specific solution that a particular client has developed over the course of some months. XmlEdit gives a user the ability load a document, edit, save changes, send it to another supplier, get the instance back and continue editing.

Below is a screenshot to give you a general idea of how it renders;

Clicking on the Edit Fragment opens up a new browser window showing only the selected ‘arc’.