CircuitData Interop

Hello CircuitData members. Our product KwickFit Online www.KwickFitOnline.com is a PCB panel layout optimizer. We have a public API for interacting with KwickFit.

 

I was thinking. If CircuitData is about exchange/integration, what would my API look like if I were to follow the CircuitData spec?  How would I handle parameters that are unique to me, like “allow part rotations”? Would I have my own wrapper with my specific properties around CircuitData? If I did that, wouldn’t I still have a custom, non-interoperable interface? If interoperability is a goal CircuitData hopes to achieve, how should this be handled?

7replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Good question. I would say that the best way to do this is to make sure that it becomes part of the language. On the other hand, if it is part of your functionality and has no generic usage, I guess the language would be filled up with unnecessary elements.

    "allow part rotations" sounds like a parameter input that you would expect into your API, and there could easily be a lot of those. As long as your output would be CircuitData schema compatible, we would achieve the goal of having everybody speak the same language, wouldn't we? Your output could be used in multiple systems and ways.

    Reply Like
  • I suppose parameters like "allow part rotations" could be part of service config only and not part of the message in. However, that may not be true for all parameters that a service requires. Generating the CircuitData output is an easy challenge, but for CircuitData to achieve what I think it hopes to achieve will require that a service accept CircuitData as input also.

    The input challenge will likely be harder because a service might get "needy" about what it requires to function.

    Reply Like
  • Thomas Monico Do you think we should separate out input as a branch of CircuitData? 

    Reply Like
  • I'm not sure. I think it's important to have a shared understanding of the CircuitData goal. It would be helpful to illustrate a "conceptual" future using CircuitData. One where an OEM kicks off a process to acquire a ready to ship product and it shows up at his door. Show the flow of CircuitData information between the various actors in the workflow. With this conceptual future illustrated, it would be easier to answer that question.

    Reply Like
  • Thomas Monico I agree. I can make some sketches, and appreciate if you and others could write/sketch down your thoughts as well.

    Reply Like
  • Continuing my previous thought... At the moment, CircuitData appears to be based on a canonical schema which will present some challenges. I worked with the mortgage industry several years ago implementing the MISMO schema in various solutions. It was challenging because of the shear scale of the schema. It's been seven years since then, so I'm not sure where they are now, but the challenges they faced are similar to the challenges that CircuitData will face.

    http://www.mismo.org/

    Reply Like 1
  • Actually, when I think about it, I guess this kind of input is a "dimension" of CircuitData just like products, profiles and capabilities. We could just add a fourth dimension for process input?

    Reply Like
reply to topic
Like Follow
  • 1 yr agoLast active
  • 7Replies
  • 222Views
  • 2 Following