Community
Participate
Working Groups
Using the synthetic sample I run Export to SMLIF from the root folder. Go to the ruleBindings page and try to add new rules. When I click on add there are no options offered for the rule or instance document
Did you click in the cells? There should be a drop down list of all document aliases and rule aliases in those respective columns. If not, it probably there are no aliases already defined, and there will be nothing you can choose in the list. You can specify aliases on page 2, and then go back to page three and you should see some available documents and rules to be bound.
I clicked on the list, the drop down was empty. So you say that I should first create aliases ?.. It doesn't look right since the aliases are created by default if none provided. The bindings page should use this default if nothing was defined by the user.
We generate aliases when you do an import, but I guess we don't when exporting from SML model units if you didn't first do an import. So I guess you're saying we should do so? If so, sounds like a good feature request.
I don't think this is a feature request. 1. The resulted smlif document does have aliases defined for every of the documents imported even if the user doesn't specify any. The rule bindings page should use the same alghoritm when deciding what to show for the alias. 2. It's not intuitive that not having an alias will stop me from creating rule bindings. In my mind, I want to link a rule with a document to be applied to and I expect to be able to provide this information in the bindings page, with or without alias support
I agree with you. I just wanted to explain that it isn't impossible with the current design to make rule bindings with your data. But I agree that the changes you suggest should be made.
(In reply to comment #3) > We generate aliases when you do an import, but I guess we don't when exporting > from SML model units if you didn't first do an import. I thought we always generate an alias. I was under the impression that the following policy is used in the order shown below: 1) Use the alias that the user has explicitly specified in the export wizard 2) Use the metadata that is generated if the user has performed an import from an SML-IF document 3) Use the workspace path of the document as the alias If this is the case, then we should always have an alias for documents exported into an SML-IF document. Valentina's suggestion does make sense (i.e. users shouldn't be forced to bind a document to an alias to bind rules to them)
I guess Valentina was saying that #3 is happening but that the GUI isn't reflecting that. I would have to extract that logic our of the ExportToSMLIF class so the GUI can make use of calculating an alias for a document that doesn't have one. Should aliases be generated/calculated for all definitions (schemas and rules) and instances?
(In reply to comment #6) > 1) Use the alias that the user has explicitly specified in the export wizard > 2) Use the metadata that is generated if the user has performed an import from > an SML-IF document IIRC, if there are aliases in the metadata, we populate the aliases in page 2 of the export wizard, but the user can change these by adding or removing aliases on that page, so it's less transparent than it might seem in your summary above.
David, >In reply to comment #7 You shouldn't determine the alias of a document and have it appear under the drop down list. It's sufficient to just show the name of the resource. I think we should always generate aliases for the documents automatically if none exists. This allows users to have SML documents referenced in other SML documents based on the policy we use to determine aliases. >In reply to comment #8 That's fine.
moving target to i8
(In reply to comment #9) > I think we should always generate aliases for the documents automatically if > none exists. This allows users to have SML documents referenced in other SML > documents based on the policy we use to determine aliases. Doesn't this violate our goal for the SML-IF document used in import to be semantically equivalent to the one generated if you immediately exported the SML documents?
(In reply to comment #11) > Doesn't this violate our goal for the SML-IF document used in import to be > semantically equivalent to the one generated if you immediately exported the > SML documents? > No, not if we use the policy I mentioned under comment #6. It's only when (1) and (2) are not available that we generate aliases. It's easier to talk about this if it's still not clear to you.
