OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emix-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [emix-comment] FW: Discussions on PAP030409


Marty,

>>> Generate equivalent schemas (OASIS style) from the UML model. Generate all schemas and table documentation directly from the UML model. This is the only way to ensure that they really have the equivalent content. This may require some work with the CIM tools that allow tailoring of the schemas generated to get the OASIS desired style correct but should not be too difficult. Worst case is there may be a small list of repeatable “post processing” manual fixes to the schemas after export. Bruce and his company have extensive experience with this method and he can get quick help if he has any problems helping us meet these goals. We are definitely not proposing maintaining a “round-trip” capability. Only UML->Schema (with appropriate post-processing if needed) and UML->Document (to produce table extracts).
<<<

I have a lot of experience with this and the OASIS CAM work and the CAM editor open source toolset.

I'm now automatically generating OASIS CS and OS schemas from CAM.  And the latest CAM v2.0 - which is almost ready for pre-release download - has modelling export capabilities.

BUT there is a big issue with going directly from UML to XSD - in that normal hierarchical design and structuring that is expected and desirable in XML instances is simply not there in UML.  In going from ERwin models to XML I've finessed this be providing an intermediary XML mechanism to inject hierarchical groupings.

But the new CAM v2.0 is a game changer - it now does drag and drop from dictionaries in visual designer mode.

So the path would be something like this - and all these steps are supported in the open source toolset:

1) Ingest current OASIS EMIX schema into CAM templates
2) Generate consolidated dictionary of XML components in CCTS format
3) From master dictionary - generate UML/XMI model
4) From each EMIX exchange template - create UML/XMI of each exchange model

Then going forward developing new exchanges

1) Create exchange outline in CAM editor - e.g. Root element, container elements.
2) Load EMIX dictionary from above - into CAM editor - drag and drop components.
3) Add new components as needed, refine rules, extend existing components.
4) Generate OASIS CS/OS schema from CAM editor tool
5) Generate XML test cases
6) Validate and iterate until exchange complete
7) Run NDR evaluation report to catch design issues.
8) Generate business documentation (HTML).

Then merge new exchange back with existing dictionary - basically start from step 2) above.

I'd be happy to setup a webinar to demonstrate these tools and techniques for the TC.

Thanks, DW

-------- Original Message --------
Subject: [emix-comment] FW: Discussions on PAP030409
From: "Marty Burns" <burnsmarty@aol.com>
Date: Thu, April 07, 2011 1:58 pm
To: <emix-comment@lists.oasis-open.org>,
<energyinterop-comment@lists.oasis-open.org>

As requested.
 
Cheers,
Marty
 
From: Marty Burns [mailto:burnsmarty@aol.com]
Sent: Saturday, April 02, 2011 11:26 AM
To: 'William Cox'
Cc: 'Aaron Snyder'; bbartell@xtensible.net; 'Gerald Gray'; ed@akuacom.com; Toby.Considine@gmail.com; 'Holmberg, David'; 'Stuart McCafferty'; 'Erich W. Gunther'; jamie.clark@oasis-open.org; eluzcando@midwestiso.org; 'Don Sturek'; jbooe@naesb.org; 'Marty Burns'
Subject: Discussions on PAP030409
 
Bill,
 
I am following up on our discussion at Nashville. Aaron and I are pushing for path modifications in EMIX and EI that will result, we believe, in a full throated support of OASIS standards emerging this year from the major utilities participating in the SGIP. We have discussed with numerous parties their reasons for the reluctance to get behind your efforts and we think that some process alterations will make an enormous difference.
 
These concepts are our own and not developed or promoted by any organization. However, they are based on our knowledgeable perceptions of status and opinions on the standards to date.
 
We believe that OpenADR, IRC, EI/EMIX/WSC, SEP2.0 represent an ecosystem of interactions. These interactions represent the repertoire of wholesale and retail demand response messaging proposed from the ISO down to customer-owned devices. As such, there needs to be a continuum of models and messaging over this scope in order to minimize mismatch, translation complexity, and information loss. Each standards community has provided its own perspective on the requirements for this messaging. EI recognizes this concept explicitly through its notion of VirtualTopNode (VTN) and VirtualEndNote(VEN) as a recursive actor/role concept throughout the network.
 
There has been a large amount of sound thinking and envisioning behind the EMIX and EI work. This has been sometimes obscured by the separation between the thinking and the detail work methodology pursued to date. We applaud the recent movements towards better UML modeling and inclusion of examples for some of the schemas. Many participants in the information model standards of the Smart Grid have converged on some best practices that maximize the ability of information models to meet original requirements, maintain consistency between models, documents, and messaging schemas, and provide for formal documentation as well as implementer’s tools.
 
We suggest that it is valuable, in order to achieve the stated goals, that the EI/EMIX/WSC standards pursue the following plan or its equivalent in trying to converge its work to completion expeditiously and effectively:
 
1)      Take the OpenADR and IRC classes and combine them into a unified (union) information model – this model should clearly identify inheritance and extensions to CIM (this had been substantially done previously – it should be resurrected and refined).
2)      Capture the EMIX model as currently envisioned by the current schemas (rev 22?) into the same EA project.
3)      The resulting EA file will have: CIM, OpenADR, IRC, EI, and EMIX packages only.
4)      Massage the result into the EI UML model without significant renaming or refactoring. This can be assisted by using the CIM profiling tools that allow this kind of massage without losing traceability (CIMEA). This approach provides built-in traceability to the key contributed works provided to the committee including the NAESB work.
5)      Generate equivalent schemas (OASIS style) from the UML model. Generate all schemas and table documentation directly from the UML model. This is the only way to ensure that they really have the equivalent content. This may require some work with the CIM tools that allow tailoring of the schemas generated to get the OASIS desired style correct but should not be too difficult. Worst case is there may be a small list of repeatable “post processing” manual fixes to the schemas after export. Bruce and his company have extensive experience with this method and he can get quick help if he has any problems helping us meet these goals. We are definitely not proposing maintaining a “round-trip” capability. Only UML->Schema (with appropriate post-processing if needed) and UML->Document (to produce table extracts).
6)      Alignment with SEP 2 means that you should be able to produce a one to one correspondence between the elements and containment hierarchy of the two. Side by side equivalent examples will assist in demonstrating this.
7)      We need examples of full messages that prove the theories of how the models work. These sample messages should be validated against the schemas that are the normative part of the standard. Best practices include verification with at least JAX and XMSpy. Experience shows that batch validations can be produced by a simple script file invoking the various parsers reducing the tedium of repeating these validations as the products evolve.
 
Bill, we identify that there are several UML and XMLSchema capable experts on the EMIX/EI teams with existing substantial time commitment to the effort – including Bruce Bartell, Gerald Gray, Ed Koch, Edgardo Luzcando, of course added to Bill Cox and Toby Considine to name a few. Divide and conquer is the metaphor for getting work done quickly and effectively as you know. I think that such an approach to implementing this plan would reliably increase the quality and adoption of the results while not slowing down the process. I believe that focus on this kind of plan followed by several weeks of internal and external review would result in a draft that would progress through the OASIS public review cycles with minimum friction and achieve the goals of this email. One or two concentrated workshops might help get the steps 1-4 completed quickly.
 
Bill, I hope you find this email an encouragement toward an excellent conclusion of the EMIX/EI process and that we can collaborate on bringing it to fruition.
 
Cheers,
Marty


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]