I'm bit confused on which scenario is best to use DTD vs XSD and vice versa. I have a requirement to validate cXML Purchase Order file. If anyone could please help, will be appreciated.
XSD has for all practical purposes superseded DTD and should be used for any new development. DTD has many limitations (e.g. no real support for data types or XML namespaces).
Related
Can somebody please guide me whether there is an overview (diagram?) showing which language elements map onto each other (or a construct in the other language) and which are unique in either BPMN or YAWL?
Can somebody please tell me which YAWL elements are not mapped onto BPMN elements and vice versa?
References: Aside from the two respective defining foundations, all I find is in-depth info is a research paper on Transformation of BPMN to YAWL (which is one-way).
Migrating YAWL files (*.ywl) to BPMN 2.0 schema files
Daniela Cristina Cascini Peixoto et. al.: A Comparison of BPMN and UML 2.0 Activity Diagrams
Workflow languages?
Map bpmn to wsdl
Which of these technology to use for BPM / Workflow engine? Any comparison of features?
Map bpmn to wsdl
Disclaimer: I am fluent in BPM (in particular BPMN), as well as graph theory in general, but I am new to YAWL.
M.F. found the a manuscript by
J.-H. Ye & S. Ye: Bidirectional mapping between YAWL and BPMN. We both do not have access to the manuscript (yet), but the abstract looks promising.
The modeling language mapping between BPMN and YAWL was researched. The transformation benefited the choice of different modeling languages and reduced duplication of development costs. As a proof of concept, the algorithm was implemented, and two open-sources plug-in called BPMN2YAWL and YAWL2BPMN are available in ProM6.0.
Source: Researchgate.net: Bidirectional mapping between YAWL and BPMN
There is a YAWL XML format definition which can be compared with the BPMN XML format definition.
[The YAWL Usergroup] would also like to point you to Apromore and a related discussion in the YAWL User Group Forum:
There is an XSD file that specifies the YAWL XML format
There is a tool called apromore which converts BPMN or other formats into the YAWL XML format.
I've spend many hours reading about DataContact and ServiceContract versioning techniques:
Best practices for API versioning?
My take away from all of these are the following
1) REST Uri's needs to be versioned.
[http://example.com/v1/car]
[http://example.com/v2/car]
2) Each REST resource operation that involves XML needs to contain XML namespace
<SampleItemCol xmlns="http://api.sample.com/2011/04/05">
<Items>
<SampleItem xmlns="http://api.sample.com/2011/04/01">
<Test xmlns="http://schemas.datacontract.org/2004/07/WcfRestService2">String content</Test>
<Id>2147483647</Id>
<StringValue>String content</StringValue>
<TestGuid>1627aea5-8e0a-4371-9022-9b504344e724</TestGuid>
</SampleItem>
<SampleItem xmlns="http://api.sample.com/2011/04/01">
<Test xmlns="http://schemas.datacontract.org/2004/07/WcfRestService2">String content</Test>
<Id>2147483647</Id>
<StringValue>String content</StringValue>
<TestGuid>1627aea5-8e0a-4371-9022-9b504344e724</TestGuid>
</SampleItem>
</Items>
</SampleItemCol>
So here are my questions:
1) Assuming there are hundreds of data contracts and many ServiceContracts, what would be the best class library structure to maintain different versions and namespaces?
2) If Uri's are versionined, do we even need to specify namespace for ServiceContracts?
3) Suppose there are 50 data contracts. All of them have namespace http://example.com/2011/04/01/. If 10 of these change and new namespace is created, http://example.com/2011/04/05/. Should the other 40 be copied to new namespace as well?
My biggest concern about REST namespaces and URI versions is the maintainability and class redundancy.
Thanks in advance for you suggestions and answers!
I went down this route with versioned service contracts and datacontracts. It was a nightmare. The worst/best part is that if you take advantage of hypermedia you really do not need to version your API at all.
If you read shonzilla's post again you will see that he is really not advocating putting versions in the URI. He shows a way to do it by using redirects, but most of his reasoning advocates against it. My previous answer to this question is here
It is also worth reading Peter Williams post on the subject.
I use XML almost exclusively for the format of my media types and I don't use namespaces at all.
and thank you for reading.
I am implementing a WCF Service based on a predefined specification (HR-XML 3.0). As such, I am starting with the schema, and working my way back to code. There are a number of large Schema documents (which import yet more Schema documents) related to my implementation, provided by this specification.
I am able to generate code using xsd.exe, by supplying the "main" and "supporting" xsd files as arguments. But there are several issues, and I am wondering if this is the right approach.
there are litterally hundreds of classes - the code file is half a meg in size
duplicate classes (ex. Type, Type1 - which both represent the same type)
there are classes declared as inheriting from a base class, but that base class is not generated/defined
I understand that there are limitations to the types of Schema supported by svcutil.exe/xsd.exe when targeting the DataContractSerializer and even XmlSerializer. My question is two-fold:
Are code generation "issues" fairly common when dealing with larger, modular xsd files? Has anyone had success with generating data contracts from OAGIS or HR-XML schema?
Given the above issues, are there better approaches to this task, avoiding generating code and working with concrete objects? Does it make better sence to read and compose a SOAP message directly, while still taking advantage of the rest of the WCF framework? I understand that I am loosing the convenience of working with .NET objects, and the framekwork-provided (de)serialization; given these losses, would it still be advantageous to base my Service on WCF? Is there some "middle ground" between working with .NET types and pure XML?
Thank you very much!
-Sasha Borodin
DFWHC.org
Sasha, If you are going to use code generation, you likely should never start with the modular schemas. When you put a code generator against the modular schemas, you'll generate a class for all the common compoents in the HR-XML library and a good bit of the common components in OAGIS. You don't want this. HR-XML is distributed with standalone schemas, which are a better starting point. An even better starting point would be to create a flattened package xsd containing only the types brought in by the WSDL. If you use a couple standalone schemas, you are going to at least have some duplications among your generated code.
Well, you could try and do something like this:
convert your XSD to C# code separately, using something like the xsd.exe tool from Microsoft, or something like Xsd2Code as a Visual Studio Plugin.
Xsd2Code in Visual Studio http://i3.codeplex.com/Project/Download/FileDownload.aspx?ProjectName=Xsd2Code&DownloadId=41336
once you have your C# classes, weed out any inconsistencies, duplications, and so forth
package everything up into a separate class library assembly
now, when generating your WCF service from the WSDL, either using Add Service Reference from Visual Studio or the svcutil.exe tool, reference that assembly with all the data classes. Doing so, WCF should skip re-creating the whole set of classes again, and use whatever is available in that data assembly
With this, you might be able to get this mess under control.
Has anybody worked on wsdl testing? Namely,
Schema validation
Semantic validation
Regression testing of WSDL
Interoperability
Does anybody have an idea of how to implement the above?
I use SoapUI for all my SOAP/REST testing. It does all the things that you want and is probably one of the most widely used tools out there.
It can also be integrated as an API. Integrating with SoapUI
For interoperability testing of WSDL's the toolkit I would recommend is that which is published by the WS-I for testing compliance against Basic Profile 1.1 and Basic Security Profile 1.0.
To download the tools look for "Interoperability Testing Tools 1.1" on the WS-I Testing tools page
Note that the test tool does 2 types of testing, a) Analysing the WSDL and b) Monitoring the traffic on the wire. I've only used the WSDL analysis.
The output from the WSDL analysis can be a pig to understand and decode and it really helps if you have a handy WSDL/XSD guru near to hand. Sadly these seem in short supply. Also it really helps to have a thorough understanding of WS-I Basic Profile beforehand (the 1.1 specification is at Basic Profile) and if you write your WSDLs to this specification then you should achieve conformance readily; which is also an argument against letting tools generate WSDLs for you as they rarely have achieving compliance as a goal.
Also note that when your WSDL comes through the analysis with a PASS this still doesn't guarantee interoperability with consumers written with the wide range of tools out there which generate proxy code from a WSDL.
At best you are getting a "stamp of approval" that gives you the best chance of meeting interoperability with the widest range of consumers. Once you do have a compliant WSDL you can claim compliance and assert this in the WSDL using the recommendations in the Conformance Claims specification.
I used to use SoapScope from MindReef (ok, I used their trials, but couldn't convince the company to buy it!) This was a very good product for compliance testing as well as for creating regression tests.
They have been purchased by Progress Software. The new URL is http://www.actional.com/mindreef/. I have not used this product they are now a part of.
You'd normally use a tool/product to do this. Altova (XMLSpy) comes to mind.
It is well-known how to create a "contract first" WCF service where the first step is to define the ServiceContracts and DataContracts.
How should one approach WCF development if one has the "schema first". In other words, an XSD schema has been independently developed. The service may not deviate from the schema that is already defined. As a complication, the schema might use features that don't translate into DataContract (the DataContract capabilities, after all, are quite minimal).
Using XDocument on the server or client side for the entire document would be fine and good. (Use of XDocument would be greatly preferred over anything involving the XmlSerializer which unfortunately seems to have fallen out of favor without replacement). It is a requirement that the metadata/WSDL properly report the actual schema per the standards. It may not report a "generic" schema such as xsd:any. (Figuring out how to deal with these WSDL requirements is the part that is giving me the most trouble.)
(Similar questions/answers here do not address XDocument or WSDL requirements.)
If you already have the XSD, the only missing link between those and a WCF interface is the WSDL. Once you have a WSDL, you can use svcutil.exe to generate WCF interfaces and classes properly annotated with the required attributes.
You can do it the hard way and write the WSDL by hand, but you also migth want to consider the WSCF tool.