Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. XML / XSL
  4. XSD importing problem

XSD importing problem

Scheduled Pinned Locked Moved XML / XSL
helpcsharpdatabasesysadminsales
1 Posts 1 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • G Offline
    G Offline
    Grimolfr
    wrote on last edited by
    #1

    I have an XSD schema file that defines data structures for a legacy EDI system (still in use.) As we're moving more and more apps to .Net, and our customers are doing the same, we're adding WebService support for processing transactions currently handled by the EDI systems. The edi definitions XSD file will be used by applications other than the new WebService, and will provide cross-compatibility for a variety of applications that communicate back and forth by passing this data around. The XSD that defines valid service requests and responses for the WebService is dependent on the edi definitions in the edi.xsd file. To provide the customer an opportunity to pre-validate transaction requests prior to sending, I have a WebMethod that returns the WebService's XSD file. The problem lies in the fact that the WebService's XSD imports the edi.xsd. Actually, this isn't much of a problem. It's a simple matter to provide a fully-qualified URL for the schemaLocation in the element. The real problem lies in the fact that both schema definitions change with some regularity. And at any one time we may have up to four separate versions of each file (dev, test, staging/cust test, production). My concern lies in this last problem. I'm concerned that if we hard-code the URL of the development edi.xsd schema into the development WebService schema, that someone may forget to change it as the WebService moves up the deployment ladder. It would be a VBT for us to have a production schema that is importing a development schema dependency. One experimental change to the development edi schema could cause the WebService to cease functioning. I know there have to be other shops that are providing dynamic XSD's with imports to their clients/customers. What's a good tried-and-true method of ensuring that each level of WebService XSD imports the correct version of the edi.xsd? Is there any way to combine the two schemas on-the-fly, so that the client only has one schema definition to look at, instead of having to find the imported schema? Alternatively, would it be possible for me to return an XmlSchema object that properly refers to the correct dependency schema(s)? I've looked into the XmlResolver, which may work for this, but I've had no success figuring out how to attach one to an XmlSchema. I've also considered returning an XmlSchemaCollection containing both schemas, but there's a bug in the framework that prevents an XmlSchemaCollection from being a return type on a WebMethod. Whenever I try

    1 Reply Last reply
    0
    Reply
    • Reply as topic
    Log in to reply
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes


    • Login

    • Don't have an account? Register

    • Login or register to search.
    • First post
      Last post
    0
    • Categories
    • Recent
    • Tags
    • Popular
    • World
    • Users
    • Groups