|
From: Mark F. B. <sa...@co...> - 2004-11-18 12:57:01
|
Hi everyone (Mark Bean here writing from home) Nice to see some of you again in the AnIML business meeting in Somerset. I finally got CVS working today and checked in a revised version into CVS schema animl-core 1.01.xsd. I also checked in a new folder under AnIML called base64_converters and in that added a C#Converters.cs file with a bunch of conversion routines, a few of which are relevant to AnIML and C#.Net implementers. If you don't have access to the CVS except in browsing, here's how I managed it. I followed a link provided by Maren Fiege, but used TortoiseCVS instead of WinCVS and have to recommend TortoiseCVS as easy to use (you check in and out from Windows Explorer). You can get TortoiseCVS from Sourceforge. To install the required client software for using AnIML CVS, follow the instructions here: http://sourceforge.net/docman/display_doc.php?docid=766&group_id=1 I also downloaded the latest enterprise version of XMLSpy and ran into a number of invalid faults in the AnIML core schema. The faults I find at work and at home are not the same using Microsoft VisualStudio.Net, but perhaps I have different versions of MSXML. I also am behind a firewall at work and that probably makes it impossible for the validator to access the schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd" for digital signatures. I suspect if I modified that to a local reference some of those errors would disappear. Anyway, here are the errors I found and what I did to "fix" them. Fix is in quotes because I don't really know XML Schema or AnIML and may have created more problems than I fixed. I believe that except for the first error, I commented out the old tags and added new tags just before it, so you can see what I did. 1.. XMLSpy: Not a valid restriction since its maxOccurs value <unbounded> is greater than 1. <xs:complexType name="VectorValueType"> <xs:annotation> <xs:documentation>Elements for IndividualValueSets in Vectors.</xs:documentation> <xs:documentation>Elements for values in Vectors.</xs:documentation> </xs:annotation> <xs:complexContent> <xs:restriction base="ParameterValueType"> <xs:choice maxOccurs="unbounded"> This is because the base complex type "ParameterValueType" has no such maxOccurs. The rule is that in order to define by restriction from a base complex type, one must only restrict, not extend. I fixed this by setting the base xs:choice to unbounded as well. 2.. XMLSpy: The complex type no name has multiple Attribute Definitions (e.g. templateid) whose type definitions is derived from ID <xs:element name="Template"> <xs:annotation> <xs:documentation>ExperimentStep templates</xs:documentation> <xs:documentation>Represents a container for ExperementStep templates</xs:documentation> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="TemplateType"> <xs:attributeGroup ref="SignableItem"/> <xs:attribute name="templateId" type="xs:ID" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> ID attributes are required to be unique. I believe the problem here is that the attributeGroup "SignableItem" has an attribute whose name is ID and type is xs:ID and that this Template element has this group by reference as well as another atrribute of the same type. Perhaps we should pay attention to what MSDN has to say about use of IDs and IDREFs and replace them with KEY and KEYREFs. Why you should favor key/keyref/unique over ID/IDREF for identity constraints DTDs provide a mechanism for specifying that an attribute has a type ID, meaning that its value will be unique within the document and that it matches the Name production in XML 1.0. IDs in XML 1.0 can also be referenced by attributes of type IDREF or IDREFS. For compatibility with DTDs, W3C XML Schema has the xs:ID, xs:IDREF and xs:IDREFS types. W3C XML Schema identity constraints are used for specifying unique values, keys or references to keys using XPath expressions defined within the scope of an element declaration. Comparing feature for feature, the identity constraint mechanisms offer more than their ID/IDREF counterparts do. For one, there is no limitation on the values or types that can be used as part of an identity constraint, whereas IDs can only be one of a specific range of values (for example, 7 is not a valid ID). A more important benefit of the schema identity constraints over ID/IDREF is that, while the latter have to be unique within the document, the former do not. In other words, the symbol space for unique IDs is the entire document, while for unique keys it is the target scope of the XPath. This is particularly useful if uniqueness is needed in two overlapping value spaces with different scopes in the same XML document. An example of this would be an XML document that contained room numbers and table numbers for a hotel. It is likely that some of the numbers overlap (i.e. there is a room 18 and a table 18), but they should not overlap within either value space. Note The W3C XML Schema family of ID types are not exactly compatible with the DTD ID types. For one, the xs:ID, xs:IDREF and xs:IDREFS types can be applied to both elements and attributes in the W3C XML Schema, although they can only apply to attributes in their DTD equivalents. Secondly, there is no restriction on how many attributes of type xs:ID can appear on an element, although such a restriction exists for ID attributes in the DTD equivalents. I added the following key and commented out the old one. I feel sure I broke something somewhere. <xs:unique name="templateIdKey"> <xs:selector xpath=".//Template"/> <xs:field xpath=" templateId"/> </xs:unique> 3.. XMLSpy: Type Definition Technique is no valid derivation of Type Definition Technique. <xs:complexType name="TemplateType"> <xs:complexContent> <xs:restriction base="ExperimentStepType"> <xs:sequence> <xs:element name="Author" type="UserInformationType" minOccurs="0"> </xs:element> <xs:element ref="Timestamp" minOccurs="0"/> <xs:element name="Technique" minOccurs="0"> I notice that there are two definitions of the element named Technique. One in ExperimentStepType and one in TemplateType. They look identical to me. I created a new complexType called Technique and then referred to it in both ExperimentStepType and TemplateType. The resultant xml schema animl-core 1.01.xsd now validated correctly. I then used the schema to generate a sample XML file for manual filling. I used the XMLSpy title bar menu item DTD/Schema:Generate Sample XML File and checked all boxes. However, I was unable to save it as it itself was invalid! Lets go through those errors: 4.. XMLSpy: The <keyfef> Identity Constraint Definition VectorIDRef did not match any elements or attributes within the scope of element IndexRef <MeasurementData id="ID000006"> <Template id="ID000007"> <PageSet id="ID000013"> <Page id="ID000014" name="token"> <References id="ID000015"> <IndexRef index="1" refWidth="1" id="ID000016" name="token" vectorID="String"/> I gave up at this point but would appreciate some help in completing the task of obtaining a valid XML file. By the way the bruker_quinine sample also had validation errors against new or old schema using XMLSpy - and that is without taking the technique validation into consideration! Microsoft has a good discussion of XML Schema design recommendations. It would be great if AnIML core were simpler. W3C XML Schema Design Patterns: Avoiding Complexity Dare Obasanjo, Microsoft Corporation http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnxml/html/ xmlschemacomplex.asp regards, Mark |