The ORM Foundation

Get the facts!

Some Ring Constraints generate errors while using OrmCustomTool to generate OIAL/XSD

Last post 07-01-2013 21:49 by Matthew Curland. 7 replies.
Page 1 of 1 (8 items)
Sort Posts: Previous Next
  • 06-27-2013 13:21

    Some Ring Constraints generate errors while using OrmCustomTool to generate OIAL/XSD

    Hello everyone,
    my name is Alessandro and I'm quite new to your community. I'm using NORMA to model a quite complex domain for my thesis work, and I've experienced the following issue affecting the OrmCustomTool generator.
    If I set a Ring Constraint to be "Symmetric and Transitive", the OrmCustomTool throws the following exception (when trying to transform that .orm file into anything else), and of course it doesn't work anymore.
    I hope this post will be useful to get this issue fixed in future releases.

    Best regards,

    Here's the exception:

    #error Exception occurred while executing transform 'ORMtoOIAL'. [CUT]
    // System.Xml.Xsl.XslTransformException
    // ERROR: Ring constraint type of "SymmetricTransitive" is not recognized.
    // in System.Xml.Xsl.Runtime.XmlQueryRuntime.ThrowException(String text)
    // in (XmlQueryRuntime {urn:schemas-microsoft-com:xslt-debug}runtime, XPathNavigator {urn:schemas-microsoft-com:xslt-debug}current, IList`1 Model, IList`1 SingleRoleMandatoryConstraints, IList`1 SingleRoleUniquenessConstraints, IList`1 ObjectTypeInformation, IList`1 FactTypeAbsorptions, IList`1 ObjectTypeAbsorptions, IList`1 TopLevelTypes, IList`1 Mandatory, IList`1 SourceRoleRef, IList`1 OilConstraintsFromParent)
    // in (XmlQueryRuntime {urn:schemas-microsoft-com:xslt-debug}runtime, XPathNavigator SourceModel)
    // in (XmlQueryRuntime {urn:schemas-microsoft-com:xslt-debug}runtime, XPathNavigator )
    // in Root(XmlQueryRuntime {urn:schemas-microsoft-com:xslt-debug}runtime)
    // in Execute(XmlQueryRuntime {urn:schemas-microsoft-com:xslt-debug}runtime)
    // in System.Xml.Xsl.XmlILCommand.Execute(Object defaultDocument, XmlResolver dataSources, XsltArgumentList argumentList, XmlSequenceWriter results)
    // in System.Xml.Xsl.XmlILCommand.Execute(Object defaultDocument, XmlResolver dataSources, XsltArgumentList argumentList, XmlWriter writer)
    // in System.Xml.Xsl.XslCompiledTransform.Transform(XmlReader input, XsltArgumentList arguments, XmlWriter results)
    // in ORMSolutions.ORMArchitect.ORMCustomTool.ORMCustomTool.XslORMGenerator.GenerateOutput(ProjectItemElement itemElement, Stream outputStream, IDictionary`2 inputFormatStreams, String defaultNamespace, IORMGeneratorItemProperties itemProperties) in c:\Users\mcurland\Documents\Visual Studio 2005\Projects\ORMPackage\Tools\ORMCustomTool\XslORMGenerator.cs:riga 365
    // in ORMSolutions.ORMArchitect.ORMCustomTool.ORMCustomTool.GenerateCode(String bstrInputFileContents, String wszDefaultNamespace, IVsGeneratorProgress pGenerateProgress, WriteReportItem report) in c:\Users\mcurland\Documents\Visual Studio 2005\Projects\ORMPackage\Tools\ORMCustomTool\ORMCustomTool.cs:riga 849
  • 06-27-2013 17:28 In reply to

    Re: Some Ring Constraints generate errors while using OrmCustomTool to generate OIAL/XSD

    Hello Alessandro,

    Thanks for your bug report.

    Please will you post an image (e.g. .png) of the part of  your object-role model that contains the ring constraint.

    This will help Matt to get a better understanding of the cause of the bug.



  • 06-28-2013 2:53 In reply to

    Re: Some Ring Constraints generate errors while using OrmCustomTool to generate OIAL/XSD

    Hello Ken,

    please find attached the simplest model in which that ring constraint produces that exception.

    Best regards,
  • 06-28-2013 4:52 In reply to

    Re: Some Ring Constraints generate errors while using OrmCustomTool to generate OIAL/XSD

     Hello Alessandro,

    Thanks for the diagram.
    Let's hope that Matt can fix this one quickly.


  • 06-28-2013 11:58 In reply to

    Re: Some Ring Constraints generate errors while using OrmCustomTool to generate OIAL/XSD

    Hello Alessandro,

    I've verified your problem with a code scan. I can get you going again with an edit in one file, but let me give you a touch of project history as to why this is not an immediate fix.

    • The error here is occurring while using XSLT to transform ORM to OIAL, which is an intermediate form that represents the ORM model in an attribute-based style. There are two versions or OIAL in use.
      1. The newer version is created as an extension (using the Extension Manager) in the .ORM file and is used for all of the current relational generation.
      2. The older version was done in XSLT only, and is currently used only for the PLIX generation. The PLIX files represent code in XML (Programming Language in XML), and are formatted in VB or C# depending on your current project type. PLIX is also used for the PHP generation. The work was done at one point to retire the old OIAL in the code generators, but unfortunately the worker walked away with the work, and I haven't replicated it.
    • The number of supported ring constraint types and combinations was expanded significantly a year or two ago. You're using a new combination.

    So, what is happening is that I didn't test the old generators with the new ring constraint types. The actual error occurs producing an oil:ringConstraint element, which is something that is never actually consumed by any of the downstream generators, so we can safely turn it off.

    To fix the problem on your machine:

    1. Find the ORMtoOIAL.xslt file in C:\Program Files\Common Files\Neumont\ORM\Transforms (use the C:\Program Files (x86)\ directory on a 64-bit machine).
    2. Open the file in an editor and look for orm:RingConstraint to find the <xsl:when test="self::orm:RingConstraint"> tag.
    3. Delete or comment out all of the child elements in this tag. If you're not familiar with XML, use the four character sequence <!-- to start a comment and --> to end the comment (there is an example a few lines earlier in the file).

    The PLIX generator will now get a lot farther.

    Getting these generators in better shape and using the new OIAL is something that needs work. They have not been touched in several years. The 'DICL to LinqToSql' mapping is a little newer. Unfortunately, there are some constructs that cause invalid PLIX to be generated, which will case another generation error. The issue here is that the formal PLIX generator requires schema-compliant PLIX, and will throw for any issue. However, if the *.PLIX.xml file itself generates, you can open this file, and then choose the 'View/Other Windows/PLiX Snippet Preview Window' to see the code. Select the plx:root element at the top of the file, and choose your view language in the PLIX window.

    Apologies for not catching this problem, and for letting this part of the project get out of date.



  • 06-29-2013 9:22 In reply to

    Which conceptual DML/DQL?

    Hello Matt,
    thanks a lot for your attention and for your quick answer.
    I've commented out that portion of ORMtoOIAL.xslt, solving that problem.

    Nevertheless, now I am trying to analyze the xml files produced by those generators in order to obtain something useful as a "fact exchange protocol" (to model interoperability among systems, they basically need to exchange "populations of facts"), and I see that none of them can be directly useful to reach this goal.
    It would be nice to have at least one "reference implementation" that maps generic fact instances to some serializable format (domain specific xml, pure text, OWL, RDF, even something more exotic like SPARQL to enable remote queries, etc..).
    I mean (more formally), since ORM(2) can be used as a conceptual DDL (data definition graphical-language), it will be very useful to have a corresponding conceptual DML (data manipulation language) or DQL (data query language) to deal with instances of facts, independently from the technology used to implement the fact database.
    Do you think this makes sense?
    It would be very useful in order to model data exchange among different businesses still remaining at conceptual level.

    Which kind of solution do you suggest for this need?

    Thank you,
    Filed under: , , ,
  • 06-29-2013 9:46 In reply to

    Re: Which conceptual DML/DQL?

     Hello Alessandro,

    You may be interested in the work of the Fact Based Modeling working group .

    The group's website has the following text:

    The main objective of the FBM WG is to transfer many years of research and business practice in the domain of semantic modeling to industry to enable industry to develop, reuse and share knowledge effectively.

    Acknowledging the existence of fact based modeling methods to produce high quality, validated solutions (e.g. relational database systems), the FBM WG focuses on the means to achieve semantic interoperability between existing modeling notations and tools by incorporating the best of each of them.


    PS: Matt is a member of this group, as am I.


  • 07-01-2013 21:49 In reply to

    Re: Which conceptual DML/DQL?

    Hello Alessandro,

    I think see where you're going. The FBM exchange Ken is talking about exchanges models (meta information), but is not really designed to exchange data for a specific model. The idea of exchange data as fact assertions and retractions is very compelling to me as well because it removes assumptions about implementations (i.e. physical mappings of a conceptual model) at the two endpoints. As long as both parties recognize the same fact types and object types, the data is easily exchanged.

    I don't have anything ready for public consumption at this point, but I'm working on an implementation stack for an ongoing consulting project that is based on physical mappings of the conceptual model on both the client and server. The architecture behind the web-based orm viewers (follow links from uses a declarative client-side (read: JavaScript) definition of orm, diagram, and orm diagram metamodels that are read by a fact-driven framework. The design of the framework is easy reading (fully navigable models that can be read using normal JavaScript code), and slightly harder writing (all changes are asserted as facts, with the framework controlling the readable storage). While the public viewers are read-only for now, editing capabilities are a fundamental part of the framework. Edits are tracked as state changes (before/after state in terms of facts for modifications, can be played forward or backward for an undo stack), and these state changes can be serialized by the framework into a JSON representation. The server then reads the JSON and translates the fact assertions into database commands.

    The eventual goal on this is to enable a rich client to do extended manipulations client side to an ORM-generated client model, then send off an arbitrarily large change request to the server. Each app has one webservice method for writing model changes, with a generated data-access layer to get the data into the database. I'm actively working on a client generator, which will be followed by a mapping from the generated client model to the generated database model. The final (per technology stack) generator will translate the incoming JSON into the database. Obviously, this is a non-trivial amount of work, but I think the benefits are huge once you get there. Basically, you get a client-side representation of your data, a service on the client to track changes and produce internally consistent JSON, a web service to read changes to the client data, and a generated data access layer to write the changes to a generated database. All you need to do this is an .orm file.

    While the client-data-to-server scenario can be easily handled, getting sufficient data (and no more) out of the database to show an individual page needs to be handled on a per-page basis. What I envision is a declarative hierarchical query structure (multiple result sets, each building on data from the other) that pulls sufficient data to populate the client model and render a given page. The difference between a derivation rule, subquery, top-level (parameterized) query, and hierarchical query is fairly minimal. I've done a lot of work on derivation rules and subqueries (see for another discussion on work-in-progress). Combining individual queries into hierarchical queries is a logical next step.

    So, while the server-side parts of this are vapor ware at this point, the client framework is relatively mature (except the generator from .orm file to produce the declarations), and I think we're thinking along the same lines for communicating data in terms of elementary facts. I had this type of stack working for a previously employer (same client stack translates changes to JSON, declaratively generated middle layer maps this to a database, and hierarchical queries can be specified on the server to retrieve initial data for a page). ORM Solutions maintained ownership of all of the client work (hence the intact ORM viewers built on the framework), but I don't have any of the server side implementation as it was targeting a proprietary deductive database backend instead of a Microsoft or LAMP stack on a relational database. So, I'm rebuilding something that I've successfully done in the recent past against a (radically) different backend platform, I've seen it working before and am highly motivated to build it up again.

    This doesn't give you a current solution directly in NORMA, but it is definitely part of the picture. If you want more details for a specific project we'll probably need to take it off line at this point.


Page 1 of 1 (8 items)
© 2008-2014 The ORM Foundation: A UK not-for-profit organisation -------------- Terms of Service