Big Picture question

SPOILER ALERT: Folks want this questions answered fast, especially those looking to a plug-fest at the end of the month.

We have been straddling the boundary between Polymorphism and Choice in the schemas for months. When I changed Signals from incompletely implemented polymorphism to using choice, the comments were many and pointed. I am leaving out the secondary issue of did I get the sometimes muddled _expression_ of intent with choice correct as a secondary issue (see my sig quoting Peter Drucker).

Here is the best write-up I have found on the issues.

http://www.ibm.com/developerworks/xml/library/ws-tip-xsdchoice/index.html

Polymorphism vs Choice in Energy Interoperation

We have generally argued for extensibility in this work which goes hand in glove with Polymorphism. In streams generally, and in Signals in particular, this would create a PayloadType, and make all elements extensions of the PayloadType, and let folks create new extensions of the PayloadType. The cost of this is some growth in objects.

For example, using Polymorphism, you can’t just put a price in a signal. As Price is already defined, you have to put a price inside a Payload, and then put this new PricePayload in a price signal. Neither difficult nor complicated. This was incompletely implemented for the last half dozen drafts, even before streams.

The social reality, though, is that for the last [period of time], there has been strong pushback on Polymorphism. This culminated in the all-purpose “amount” which might be a Price, might be Watts, might be a shoe size. This argued that whatever the support for Polymorphism, when it came down to it, practitioners wanted simple elements, already derived. No PricePayload, not even the already defined EmixPrice, but a simple element, simply expressed, whose meaning could be discovered elsewhere in the document.

Identifying an element elsewhere in the document is architecturally problematic / processing intense / rarely considered best practice. It also seemed to provide strong guidance away from polymorphism. It also meant that we failed to re-use expressions in other specifications that we said we would in our charter, and in PAP09, and in…

So in WD29 WIP2, I swung over to Choice, giving up extension, but keeping simpler objects defined already.

It is a matter of moments switch back to the extensibility model, but if we use the extensibility model, we should use it, and no overload a few favored or historically significant communications. “All of these values are the same except when we extend instead” in not an architecturally / semantically / coding-wise consistent approach.

As editor, I turn to the TC for guidance and say: Polymorphism or Choice. Pick one. Whichever we pick, we will use consistently across Signals / Baselines / Feedback.

If Choice is the one, then I can spend the time to un-muddle the syntax of constrained choice later.

Thanks

"If something is not worth doing, it`s not worth doing well" - Peter Drucker

Toby Considine
TC9, Inc

TC Chair: oBIX & WS-Calendar

TC Editor: EMIX, EnergyInterop

U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

Email: Toby.Considine@gmail.com
Phone: (919)619-2104

http://www.tcnine.com/
blog: www.NewDaedalus.com

energyinterop message