Community
Participate
Working Groups
There are several instances where a more specific URI is needed in an itemRef in the datacenter sample. I noticed the first instance of this when I exported the datacenter to an SML-IF file and got the following validation error: Target Element Error: itemRef on line 2593 column 32 references dataCollection/TPTP_GenericLogAdapter/GLAControllerWin.xml that is not of type it:itemType The data in that section is that which originally came from topology/machine2Win.xml. At Valentina's suggestion, I changed the itemRef as follows to include an #xpointer reference, and this caused the the error to disappear: <sml:uri>dataCollection/TPTP_GenericLogAdapter/GLAControllerWin.xml#xpointer(/gla:glaController)</sml:uri> After running the validator again, I noticed the error occurring again in further locations. Here's an example from topology/machine2Win.xml: <it:itemRef sml:ref="true"> <sml:uri>os/windows/WindowsServer1.xml</sml:uri> </it:itemRef> Since there are several examples of these, and since this is one case where the validator doesn't report multiple errors at once, I will leave finding these as an exercise for the defect assignee. :-)
Thanks David; I'll fix this
moving target to i8
Ruth, I am moving this to you so that you can reassign as you find appropriate
John, please see if this is still valid. Thanks!
It probably is. This is actually a more complex question than any normal human would imagine, but then I write standards :-) The file he changed (GLAControllerWin.xml) is not valid with respect to its schema in its original state (and at least one of its schema files is also invalid). From a purely SML perspective, the model is invalid and that's all you can reliably say. SML does not guarantee that a validator will give you all possible validation errors, for example. Depending upon how the schema validation errors are fixed (if they should be, read on), the message Steve cited might also be fixed as a consequence. I also don't know if the original intent was that this example should be a valid SML model. Someone with more historical context would have to supply that answer, or (if it is all gone now) then the community needs to decide what kind of example it does want (it might want both valid and invalid examples).
These defects were assigned to Steve because he was the former RM lead, and was therefore the default assignee, but I was the one who created the defects. I was under the impression that you and Valentina had worked together on the datacenter example. She had intended for it to be an example of a data center using SML, so yes, it should be valid. She often asked us to make sure the validator would be able to validate the example correctly, and I don't think it ever worked all the way. So you might not want to spend the time with this, as it might not rate high on importance, but if it doesn't take a great deal of work to get the example in the shape, I think it can be a great showcase of SML. However, if it's too far into disrepair, we should probably remove it totally.
Created attachment 136224 [details] Fixes XML Schema (-not- SML) validation errors Net: integrate this patch to advance the cause, but leave the bug open since there is yet more to do. I have the first class of errors fixed in this patch, so what is here all successfully -XML Schema- validates. That's as far as I can get for now. When I tried to SML-IF validate it, I got 19 "duplicate alias" errors ... and since the COSMOS code is creating the SML-IF document being validated from the directory structure, those are "suspicious" (i.e. likely to be a COSMOS code bug). There were another 35 errors related to a moved file on the W3C site (apparently the validator plug-in is still trying to use the W3C site's SML schema somehow instead of the workspace-resident copy, and the W3C URL is now returning a name space policy document ... as it should have all along ... rather than a schema document).
Do these changes depend on the changes for bug 276993? Or is it safe to integrate this code without the code for 276993?
(In reply to comment #8) The two bugs are orthogonal, so it is safe. It even happens to be true that I coded this one first, so patching in this order actually matches the order things were done in my workspace.
reviewed and checked in to CVS HEAD
Oops, forgot to leave this open. As John said, there is more to do.
