1
Is there a plugin API to extend XSD Designer?
Question asked by Mark Kozak - 1/27/2025 at 10:20 PM
Answered
I have a custom XSD parser that expects certain attributes in my element definitions. I don’t mean the elements in the resulting  xml have attributes, I mean actual xsd definition has these attributes. A simple example shown below
 
<element name="my_date" type="xs:date"   my_namespace:calendarPattern="yyyymmdd" />
My parser accepts a stream of data and uses the xsd schema to create a xml output. In this example it uses the calendarPattern attribute know how the incoming eight digits should be used to create a valid xml date. Sometimes the data could contain an alternate pattern like mmddyyyy, so a schema file is used to inform the parser. There are several dozen custom attributes that can be added, depending on the element type. Everything works great when the xsd is written by hand. But would love to be able to use the design view to graphically edit the schema. I need a way to enforce the inclusion of the calendarPattern attribute every time the element type is xs:date. Furthermore, I need to restrict the possible values for that attribute to be either the string  “yyyymmdd” or “mmddyyyy” as those are the two valid options my parser knows ho to deal with.
 
Ideally I could accomplish this with some sort of xml / xsd file that Studio uses to populate all of its components. But I would just as thrilled if there is a plugin API that I could use to extend this capability. My goal is to allow my customers, the users of the custom parser, to more easily create and edit xsd files. I want to be able to tell them to go buy a license for the graphical xsd editor, and with my extension they can create xsd files that will work with the parser. Is that something that is possible?

4 Replies

Reply to Thread
0
Liquid Support Replied
Employee Post Marked As Answer
The graphical XSD editor will retain your custom attributes (calendarPattern) within the element, and allow you to edit them in the text view, however as our parser has no knowledge of the attributes you have created or there meaning, there is no way to graphically edit, validate or enforce their use, and there is no API interface.

A couple of thoughts 
By changing the format of the xs:date type to be 'mmddyyyy' rather than the format in the W3C standard (https://www.w3.org/TR/xmlschema11-2/#date), you are making your XML documents invalid against the schema, which significantly reduces the value of having a schema.

Maybe a better solution would be to have an XSD containing standard definitions which you include into your schemas. This could contain derived type definitions, i.e. USDate, UKDate etc.

These types would be defined as xs:string and could have regex patterns that enforce there validity. Of course someone could still use an xs:date in their schema but the format for this is very strict so there is never any ambiguity. Or you could have a post process step that flags up the use of types you want to manage your self.

An example for extending types can be found in our XML Schema tutorials.

0
Mark Kozak Replied
Thanks for the quick reply, but I think my question needs a little more clarification. The input data stream containing the mmddyyyy is not XML. The purpose of the parser is to turn that stream into 100% compliant XML as the output. So the parse uses the XSD schema to know how to read the non-XML and which XML data type to transform it into. I was really hoping to avoid writing my own GUI from scratch as the your tool has a perfect workflow for what I need, if only it supported added attributes.
0
Liquid Support Replied
Employee Post
OK, thanks for the clarification.

Would it not be more convenient our Graphical Data Mapper tool to do the transform? Maybe if you create a support ticket and send a zip of your sample input/output we could offer a better solution.
0
Mark Kozak Replied
I appreciate the offer to see if there are other approaches that might work, given a set of sample data. However the input data is not static. If it was I would invest the one time effort to create the schema in the first place. The problem is I don't know what the format of future data will be, and I am looking for a way to simplify the creation.

I good way to better explain what I am trying to do is reference ogf.org/ogf/doku.php/standards/dfdl/dfdl and github.com/DFDLSchemas/CSV/tree/master/src. What I am working with is similar to the the schemas in that repo.

Reply to Thread