c# XDocument Xsd pattern validation with character $ - validation

I have a problem with c# XDocument XSD validation.
The following file is validated well by Xml Spy, but not by .Net (c#)
<Root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="Simple.xsd">
<Var Name="$Toto"/>
</Root>
Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="Root">
<xs:complexType>
<xs:sequence>
<xs:element name="Var">
<xs:complexType>
<xs:attribute name="Name" type="ST_VariableIdentifier" use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:simpleType name="ST_VariableIdentifier">
<xs:restriction base="xs:string">
<xs:pattern value="$[a-z,A-Z]*"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
An idea?

This should work!
<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="Root">
<xs:complexType>
<xs:sequence>
<xs:element name="Var">
<xs:complexType>
<xs:attribute name="Name" type="ST_VariableIdentifier" use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:simpleType name="ST_VariableIdentifier">
<xs:restriction base="xs:string">
<xs:pattern value="[$][a-z,A-Z]*"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>

Just to add to the existing answer. This is actually a known 'bug' in the .Net implementation of the W3C specs (acknowledged here on Connect, but Won't fix).
MSDN provides more information (here), together with the workaround mentioned above.
The System.Xml implementation of the World Wide Web Consortium (W3C)
Recommendations for XML Schemas uses the RegEx class to perform
pattern matching of regular expressions. In some cases, the behavior
recommended by W3C differs from the RegEx class behavior. The
following are the known cases where the System.Xml implementation of
pattern matching differs from the W3C specification:
According to the W3C for XML Schema specification, the dollar sign ($)
should be treated as a regular character. However, the System.Xml
validation interprets a dollar sign in the xs:pattern as an
end-of-line anchor. The possible workaround is to replace $ with [$].
If your pattern is already in brackets, such as [abc$], it is not
necessary to make any changes.

Related

BizTalk BlobStorageAdapter - Promote Blob Metadata as BizTalk properties

I'm using the AzureBlobStorage adapter in BizTalk 2020 and to receive blobs from Azure Blob Storage. The blobs have metadata which I want to use within my orchestration. So I created and deployed a schema containing the metadata keys as elements.
Within the receive location I entered the "Namespace for blob metadata" with the namespace of my schema and checked the checkbox "Promote metadata properties"
Unfortunately I'm getting the following error: "Loading property information by list by namespace failed or property not found in the list. Verify that the schema is deployed properly."
Schema:
<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns="http://POC.Test.AzBlobMetadata.AzLaParameters" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" targetNamespace="http://POC.Test.AzBlobMetadata.AzLaParameters" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:annotation>
<xs:appinfo>
<b:schemaInfo schema_type="AzLaParameters" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" />
</xs:appinfo>
</xs:annotation>
<xs:element name="MetaData">
<xs:complexType>
<xs:sequence>
<xs:element name="la_name" type="xs:string" />
<xs:element name="la_runid" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Receive Location / Adapter configuration:

Generating soap service and POJO classes from xsd and wsdl

I am creating a soap service by consuming one wsdl and multiple xsd files. The xsd files are included in my wsdl. I have tried with jaxws and cxf plugins using maven. Both the plugins are throwing error/exception while parsing the wsdl.
below is the error from jaxws:
[ERROR] Invalid wsdl:operation "insertSubscriber": its a document-literal operation, message part must refer to a schema element declaration
CXF dies without throwing any error description.
The jxc framework creates the classes from xsd files but they are of no use because I have to create endpoints manually and the linking of the classes is already defined in my wsdl.
I have also C++ gsoap client which uses the same wsdl and xsds using which I can create my soap service, But I want to migrate my service to a java application. How do I fix the above problem?
wsdl snippet:
<wsdl:import namespace="MyDomain/mytypes" location="MyTypes1.xsd"/>
<xsd:complexType name="insertSubscriberRequest">
<xsd:sequence>
<xsd:element name="insertAddressList" type="mytypes:InsertAddressList"/>
</xsd:sequence>
</xsd:complexType>
<wsdl:message name="insertSubscriberRequest">
<wsdl:part name="insertSubscriberRequest" type="tns:insertSubscriberRequest"/>
</wsdl:message>
<!--wsdl operation-->
<wsdl:portType name="myService">
<wsdl:operation name="insertSubscriber">
<wsdl:input message="tns:insertSubscriberRequest"/>
<wsdl:output message="tns:insertSubscriberResponse"/>
</wsdl:operation>
</wsdl:portType>
<!--soap operation-->
<wsdl:operation name="insertSubscriber">
<soap:operation soapAction="MyDomain/mytypes/insertSubscriber"/>
<wsdl:input>
<soap:body use="literal" namespace="MyDomain/mytypes"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal" namespace="MyDomain/mytypes"/>
</wsdl:output>
</wsdl:operation>
snippet from MyTypes1.xsd:
<xs:complexType name="InsertAddressList">
<xs:annotation>
<xs:documentation>Definition of a list of Account IDs for Insert operation</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="accountId" type="MyType2:sdsAccountId" minOccurs="10" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
snippet from MyTypes2.xsd
<xs:simpleType name="sdsAccountId">
<xs:annotation>
<xs:documentation>Definition of Account ID parameter</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:minLength value="1"/>
<xs:maxLength value="26"/>
<xs:pattern value="([0..9]){1,26}"/>
</xs:restriction>
</xs:simpleType>
I verified the WSDL file and there was an import error. Actually, It was importing the xsds two times once in the wsdl:definitions and once in the xsd:schema. removing the import from the wsdl:definitions worked for me,
With wsimport I am facing the same issue, but it is working with cxf.

In an Office add-in manifest, why must <Permissions> immediately follow <FormSettings/>?

This issue is best demonstrated by example. Consider the following:
In the first example, my <Permissions/> element is placed immediately after the <FormSettings/> block:
<?xml version="1.0" encoding="UTF-8"?>
<OfficeApp xmlns="http://schemas.microsoft.com/office/appforoffice/1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:bt="http://schemas.microsoft.com/office/officeappbasictypes/1.0" xmlns:mailappor="http://schemas.microsoft.com/office/mailappversionoverrides/1.0" xsi:type="MailApp">
<Id>464672b2-35a8-44a1-8c06-3ad07ed893a7</Id>
<Version>1.0.0.0</Version>
<ProviderName>Example</ProviderName>
<DefaultLocale>en-US</DefaultLocale>
<DisplayName DefaultValue="Example A"/>
<Description DefaultValue="This is an example add-in."/>
<IconUrl DefaultValue="https://placehold.it/64x64"/>
<HighResolutionIconUrl DefaultValue="https://placehold.it/64x64"/>
<SupportUrl DefaultValue="https://example.com/"/>
<Hosts>
<Host Name="Mailbox"/>
</Hosts>
<Requirements>
<Sets>
<Set Name="MailBox" MinVersion="1.1"/>
</Sets>
</Requirements>
<FormSettings>
<Form xsi:type="ItemEdit">
<DesktopSettings>
<SourceLocation DefaultValue="https://example.com"/>
</DesktopSettings>
</Form>
</FormSettings>
<Permissions>ReadWriteMailbox</Permissions>
<Rule xsi:type="RuleCollection" Mode="And">
<Rule xsi:type="ItemIs" ItemType="Message" FormType="Edit"/>
</Rule>
</OfficeApp>
I am able to successfully add this manifest to my Exchange Admin Center's organization add-ins list.
However, if I move the <Permissions/> element anywhere else in the manifest, the manifest fails validation when attempting to add it:
<?xml version="1.0" encoding="UTF-8"?>
<OfficeApp xmlns="http://schemas.microsoft.com/office/appforoffice/1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:bt="http://schemas.microsoft.com/office/officeappbasictypes/1.0" xmlns:mailappor="http://schemas.microsoft.com/office/mailappversionoverrides/1.0" xsi:type="MailApp">
<Id>464672b2-35a8-44a1-8c06-3ad07ed893a7</Id>
<Version>1.0.0.0</Version>
<ProviderName>Example</ProviderName>
<DefaultLocale>en-US</DefaultLocale>
<DisplayName DefaultValue="Example A"/>
<Description DefaultValue="This is an example add-in."/>
<IconUrl DefaultValue="https://placehold.it/64x64"/>
<HighResolutionIconUrl DefaultValue="https://placehold.it/64x64"/>
<SupportUrl DefaultValue="https://example.com/"/>
<Hosts>
<Host Name="Mailbox"/>
</Hosts>
<Requirements>
<Sets>
<Set Name="MailBox" MinVersion="1.1"/>
</Sets>
</Requirements>
<FormSettings>
<Form xsi:type="ItemEdit">
<DesktopSettings>
<SourceLocation DefaultValue="https://example.com"/>
</DesktopSettings>
</Form>
</FormSettings>
<Rule xsi:type="RuleCollection" Mode="And">
<Rule xsi:type="ItemIs" ItemType="Message" FormType="Edit"/>
</Rule>
<Permissions>ReadWriteMailbox</Permissions>
</OfficeApp>
Attempting to add this manifest to my Exchange Admin Center's organization add-ins list produces the following error:
This app can't be installed. The manifest file doesn't conform to the schema definition. The element 'OfficeApp' in namespace 'http://schemas.microsoft.com/office/appforoffice/1.1' has invalid child element 'Permissions' in namespace 'http://schemas.microsoft.com/office/appforoffice/1.1'. List of possible elements expected: 'DisableEntityHighlighting' in namespace 'http://schemas.microsoft.com/office/appforoffice/1.1' as well as 'VersionOverrides' in namespace 'http://schemas.microsoft.com/office/mailappversionoverrides' as well as any element in namespace 'http://www.w3.org/2000/09/xmldsig#'...
It is only through trial and error were we able to find the root cause of this validation failure.
My question: Why does ordering matter? Why can the <Permissions/> element not appear anywhere within the same nesting level in the manifest?
Context
This validation failure occurs in hosted Exchange (Office 365), and also when attempting to submit an add-in to the Office Store, at the step where a manifest is requested.
Why does ordering matter?
Order of the tags defined by schema file. In your case you have included in the manifest http://schemas.microsoft.com/office/appforoffice/1.1 Schema. Try to find in the schema <Permissions/> element and you will see the following definition ...
<xs:complexType name="MailApp">
<xs:complexContent>
<xs:extension base="OfficeApp">
<xs:sequence>
<xs:element name="Requirements" type="MailAppRequirements" minOccurs="1" maxOccurs="1"/>
<xs:element name="FormSettings" type="FormSettings" minOccurs="1" maxOccurs="1"/>
<xs:element name="Permissions" minOccurs="0" maxOccurs="1" type="ST_Permissions2"/>
<xs:element name="Rule" type="Rule" minOccurs="1" maxOccurs="1"/>
<xs:element name="DisableEntityHighlighting" type="xs:boolean" minOccurs="0" maxOccurs="1"/>
<xs:element ref="mailor:VersionOverrides" minOccurs="0" maxOccurs="1"/>
<xs:any id="MailAppSignature" minOccurs="0" maxOccurs="1" namespace="http://www.w3.org/2000/09/xmldsig#" processContents="lax"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
Element <Permissions/> is in the <sequence/> which means it must be in order defined by this element and it's right after <FormSettings/> and nowhere elese.
Order of the tags defined by schema file. Unfortunately this is not well documented and we are working to improve this documentation. Order matters when defining a manifest for Outlook web add-ins because of the way we validate the schema for installation. We realize this can be a hassle especially since it's not well documented but the main reason we require a specific order is because it allows us to validate the manifest content quickly and increase performance of the service.
Thank you for providing this feedback on our documentation.

Why am I getting different validation between an XSD regex with Nokogiri and normal Ruby regular expressions?

I have an XSD schema that includes a rule for a specific field to match the following regex:
\d{8}[\-]?[A-Za-z]{0,3}
Using irb, I can test with this regex and the following strings all match, which is correct:
12345678
12345678-
12345678-abc
12345678abc
When I attempt to validate some XML against this XSD, I get slightly different behaviour:
Passes:
12345678-
12345678-abc
12345678abc
Fails:
12345678
And here is a mimimal XSD/XML files that reproduces this:
<?xml version="1.0" encoding="utf-8"?>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:simpleType name="codeType">
<xs:restriction base="xs:token">
<xs:pattern value="\d{8}[\-]?[A-Za-z]{0,3}"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="test">
<xs:complexType>
<xs:sequence>
<xs:element type="codeType" name="code"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
And XML:
<?xml version="1.0" encoding="UTF-8"?>
<test>
<code>11034755</code>
</test>
And running this with
xmllint --schema test.xsd test.xml
Gives
Element 'code': [facet 'pattern'] The value '11034755' is not accepted by the pattern '\d{8}[\-]?[A-Za-z]{0,3}'
While XML schema does not have full regular expressions, this should be valid I think. What am I not understanding when it comes to regular expressions in XSD files in this particular case with regards to '?' ?
Using Rubular to test /\d{8}-?(?:[a-zA-Z]{3})?/ I get hits for all strings.
Alternately /\d{8}[a-zA-Z-]*/, /\d{8}[a-z-]*/i, and /\d{8}[a-z-]{0,4}/i work also.
You can use {0,3} or {,3} so those might help.

What is wrong with this XPath Expression in a jaxb bindings file?

trying to evaluate the XPath expression
/xs:schema/xs:element[#name='StrikeOptionReservationSummaryData']/xs:complexType
with the following document produces an XPathExpressionException
<xs:schema>
<xs:element name="StrikeOptionReservationSummaryData">
<xs:complexType>
...
</xs:complexType>
</xs:element>
<xs:schema>
The error from from xjc is [ERROR] XPath error: null
What is wrong with this?
It's a lousy diagnostic, but perhaps you didn't give the XPath processor a binding for the namespace prefix "xs"?

Resources