Can we do the following? If not, can you guide me to choose the attribute group in xsd.
<xsd:complexType name="getGroupType">
<xsd:choice minOccurs="1" maxOccurs="1">
<xsd:attributeGroup ref="groupA"/>
<xsd:attributeGroup ref="groupB"/>
</xsd:choice>
</xsd:complexType>
xsd:choice is called a model group and can only be used with elements, not with attributes. However, it may be possible to emulate a choice on an attribute group using subtypes (two types extending a base one).
Related
I have the following definitions in the XML Schema:
<xsd:complexType name="ExpressionType" abstract="true"/>
<xsd:complexType name="PropertyNameType">
<xsd:complexContent mixed="true">
<xsd:extension base="ogc:ExpressionType"/>
</xsd:complexContent>
</xsd:complexType>
What does the PropertyNameType actually allow as content? Just textual content or is there more to it?
PropertyNameType is a complex type with complex content and mixed="true", extending another empty abstract complex type. That's all. My question is, which content it may have.
It may clearly have textual content (because of mixed="true"). But is something else allowed? Or is there some extension method which would put more stuff in, something with substitution groups perhaps?
To answer your question: No, only textual content is allowed.
So if the element test is defined as:
<xs:element name="test" type="PropertyNameType" />
Then the only valid content is:
<test>Hello World!</test>
No attributes, no child elements.
The question in short - "can I define a schema within a schema which can be validated as a whole?
Explanation:
Is it possible to define a schema for the following XML. I need to define a schema for "customer". The "customertype" child element itself is a schema. Within the customertype I should have an element called "Source" which is mandatory.
<customer>
<customername>acustomer</customername>
<customertype>
<xs:schema>
<xs:element name="profession">
<xs:complexType>
<xs:sequence>
<xs:element name="Source" type="xs:int" />
<xs:element name="ProfessionName" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:schema>
</customertype>
</customer>
Is it possible to Define the schema for this xml so that all the requirements are met?
As Mimo has pointed out, there's no problem defining customertype (or another other element) as containing elements in the XSD namespace, which is what you appear to be asking about.
But if your goal is to be able to validate customer elements (or profession elements, which is what the schema in your example declares), it's hard to imagine a validation architecture in which that's the best way (or even a workable way) to go about it. One reason is that validating a document instance against schema information provided by the instance being validated doesn't produce the same confidence in the data's cleanliness as validating it against a known schema. (Put yourself in the shoes of an adversary seeking to subvert your validation and persuade your system to accept bogus data as valid. If the adversary gets to specify what counts as a valid document instance, how useful is it to know that the document is valid?)
What is it that prevents you from writing a schema and using it in the usual way?
[Addition, 15 October 2012, after OP's comment]
If I've understood your comment of earlier today correctly, your requirement is to allow people other than you to specify the type of the customer element however they like, subject to the proviso that that type must contain a child element named Source, whose type will be xsd:int. You don't specify whether you need access to the type definition they are using or not, so I'll try to consider both the case where you do need it and the case where you don't need it.
Three ways to make this situation work are described below. They have in common that there is
a 'main' schema document that defines a basic version of the schema, and
one or more 'auxiliary' schema documents for use in different situations.
In general, you may find it helpful to find a good textbook on XSD and review what it says about creating a schema from declarations in several schema documents.
(1) One approach uses xsi:type. You define a main schema document in which the customer element has a named type; I'll assume the type is named Customer. The Customer type accepts any element whose first child element is named Source. For example:
<xs:element name="customer" type="Customer"/>
<xs:complexType name="Customer">
<xs:sequence>
<xs:element name="Source" type="xs:int"/>
<xs:any minOccurs="0"
maxOccurs="unbounded"
processContents="lax"/>
</xs:sequence>
<xs:anyAttribute processContents="lax"/>
</xs:complexType>
Those who want a more specific type for the customer element (I'll call them the 'users') provide auxiliary schema documents for your target namespace in which they declare other complex types which restrict Customer. For example, they might want the customer element to contain elements called name, address, and phone number:
<xs:complexType name="Customer-for-us">
<xs:complexContent>
<xs:restriction base="Customer">
<xs:sequence>
<xs:element name="Source" type="xs:int"/>
<xs:element ref="name"/>
<xs:element ref="address"/>
<xs:element ref="phone"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
This is a legal restriction of the Customer type, so the customer element can use it. A document instance might therefore contain an element like:
<customer xsi:type="Customer-for-us">
<Source>83760273</Source>
<name>Willy Wonka</name>
<address> ... </address>
<phone> ... </phone>
</customer>
The document is validated against the schema constructed from their auxiliary schema document, together with the main schema document, so the definition of type Customer-for-us is enforced in the usual way.
By using wildcards and lax validation, the Customer type ensures that users can do anything they like in their version of the type, as long as the first child is named Source and has type int.
(2) A second approach uses a hole in the main schema document.
You write a main schema document as before, including the declaration of the customer element as having type Customer. But the main schema document does not contain a declaration for that type. Instead, you declare the Customer type in an auxiliary schema document, which is combined with the main one at validation time in the usual way (I'd recommend you have a third schema document which serves as a driver and includes the other two, but there are many ways to make it work).
The users who want a more specific Customer type, meanwhile, write their own declaration for the Customer type, subject to the compatibility constraints about the first child named Source and so on. The users use their own driver file, which embeds the main schema document and their version of the auxiliary schema document with their own declaration of the Customer type.
This way, the xsi:type attribute does not need to be used.
(3) A third approach uses the xs:redefine or (in XSD 1.1) the xs:override facility.
You write the main schema document as described in solution (1). The users use xs:redefine or xs:override to redefine Customer as they wish. This answer is already rather long, so I do not propose to include a tutorial on the use of either redefine or override.
It is possible to create a schema importing and using another schema. This defines your customer element with customertype containing a schema:
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://xml.netbeans.org/schema/Notes"
xmlns:tns="http://xml.netbeans.org/schema/Notes"
elementFormDefault="qualified">
<xsd:import namespace="http://www.w3.org/2001/XMLSchema"/>
<xsd:element name="customer">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="customername" type="xsd:string"/>
<xsd:element name="customertype">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="xsd:schema"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
The problem is that you have an additional condition on the customertype schema - so you should in theory get the standard XSD schema and modify it, but there are many different ways to satisfy that condition in a schema definition, so it is very tricky (and maybe impossible) to do this 'modification'
Probably a better approach is restrict the possible schemas used inside customertype (e.g. it must be a single element definition with complex type specified directly etc. etc) and write a sub-set of the XSD schema that describe this restricted schema definition.
I have below complextype
<xsd:complexType name="cidType">
<xsd:choice>
<xsd:sequence>
<xsd:element name="a" type="Type_A"></xsd:element>
<xsd:element name="b" type="Type_B"></xsd:element>
</xsd:sequence>
<xsd:element name="b" type="Type_B"></xsd:element>
</xsd:choice>
</xsd:complexType>
When trying to generate JAXB classes for this schema it's wrong, because, as you see, is repeated reference to the element b the JAXB error gives me is:
/*
* You are getting this "catch-all" property because of the following reason:
* The field name "b" is used by two different parts of a schema.
*/
Since it is an industry standard schema I don't have the liberty to change anything. What is the possible solution?
If i go the customization route, i don't know how to, if possible please point me to a good resource/example. I have already tried my luck with google
I do have an external binding declaration to incorporate data type for some of the elements, but I am not sure how I can use the binding customization to solve my current problem
SDL Tridion uses XML schema definitions to define content stored in Tridion components. XSD can use restrictions/facets or indicators to restrict what's valid for XML nodes.
Chris Summers found some of these accidentally in training, specifically that we can set minOccurs and maxOccurs indicators in SDL Tridion 2011 as in:
<xsd:element name="someField" minOccurs="2" maxOccurs="5" type="xsd:normalizedString">
Andrey Marchuk mentions additional options in the same post:
Indicators
MaxValue
MinValue
Restrictions
FractionDigits
MaxLength
MinLength
Pattern
TotalDigits
Btw, are these XSD-specific?
IsMaxValueExclusive
IsMinValueExclusive
How would I get the *restrictions into the following sample Tridion schema (source)?*
<xsd:schema xmlns="http://createandbreak.net/schema/example" xmlns:tcmi="http://www.tridion.com/ContentManager/5.0/Instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" targetNamespace="http://createandbreak.net/schema/example">
<xsd:import namespace="http://www.tridion.com/ContentManager/5.0/Instance"></xsd:import>
<xsd:annotation>
<xsd:appinfo>
<tcm:Labels xmlns:tcm="http://www.tridion.com/ContentManager/5.0">
<tcm:Label ElementName="someField" Metadata="false">someField</tcm:Label>
</tcm:Labels>
</xsd:appinfo>
</xsd:annotation>
<xsd:element name="Content">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="someField" minOccurs="2" maxOccurs="5" type="xsd:normalizedString">
<xsd:annotation>
<xsd:appinfo>
<tcm:ExtensionXml xmlns:tcm="http://www.tridion.com/ContentManager/5.0"></tcm:ExtensionXml>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
To take an example from W3Schools, this would be a non-Tridion XSD restricting a field to 5 digits using a regular expression:
<xs:element name="prodid">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:pattern value="[0-9][0-9][0-9][0-9][0-9]"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
I tried changing the xs namespace to xsd but I'm not sure where XSD restrictions would go in the (Tridion) schema.
I believe the XS and XSD is somewhat irrelevant here. Both are actually namespace prefixes which refer to the same namespace. This is described in this post.
If you look at a sample from the site you quoted (http://www.w3schools.com/schema/default.asp) you will see that the xs namespace prefix refers to http://www.w3.org/2001/XMLSchema which is the same as xsd in the Tridion schema.
E.g.
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
therefore xsd is the same as xs.
Or am I completely missing your point?
If you are just looking on how to apply restrictions, this comes from the SDL Tridion docs (here but requires password):
<xsd:element name="NumberFieldWithMultipleFacets">
<xsd:simpleType>
<xsd:restriction base="xsd:decimal">
<xsd:totalDigits value="4"/>
<xsd:fractionDigits value="2"/>
<xsd:minInclusive value="10"/>
<xsd:maxInclusive value="20"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
If you are looking for a list of the possible facets in Xml Schema, then you need to look here. Perhaps then it's a simple matter to check which of these are respected/supported by Tridion
I still miss xsd:ID for example, works in WebForms (yes, from version 1.0), but not in the latest SDL Tridion GUI (except 2013, not tested).
I would like all valid xsd's to work in the Tridion GUI.
And for example, that content editors will see a counter when you limit a text field to be min="30" max="70" characters.
Would be a very nice GUI update.
Because it would make WebForms possible in the normal(!) Tridion GUI.
Creating new fields will then be possible by content management.
Creating new HTML5 webforms (tested!) takes then less then 2 minutes.
So please update the GUI to full xsd support.
Hi all i am an XML Schema where i have the following
<xsd:element name="Check" type="CheckboxType">
<xsd:annotation>
<xsd:documentation>
<Description>Check</Description>
<LineNumber>12</LineNumber>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
While assigning the value or inner text for this field it is taking only X. What's the other value that i can pass other than X. I think X is assigned when i checked a check box, but what's the other value that i can assign to that Node when check box was not checked
There are multiple ways to specify an absence of a value. Below two are two generic ways.
Option 1
Do not add the element in the XML instance. If this is the right option or not is dependent upon the context and hard to tell without knowing more information
Option 2
Use xsi:nil="true" attribute in the XML instance. You can read more about the usage on zvon.org. To use this change your element definition as below
<xsd:element name="Check" type="CheckboxType" nillable="true">
<xsd:annotation>
<xsd:documentation>
<Description>Check</Description>
<LineNumber>12</LineNumber>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
You can then have the XML instance as below
<Check xsi:nil="true" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" />