473,225 Members | 1,375 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,225 software developers and data experts.

XmlValidatingReader DTD validation

I have the following code:
I have a local copy of the DTD that I need to validate incoming XML
documents against.
The XML document has the <!DOCTYPE myname SYSTEM "myfile.dtd"> define.
When the following code is executed the XML gets resolved through the
XMLResolver and gets correctly validated against the locally stored DTD
file.
The problem occurs when the incoming XML contains no DOCTYPE attribute. The
resolver code never gets called and the validation does not occur at all.
What am I doing wrong here? Is that a bug and there is no way to enforce
the DTD even if the icoming XML file does not specify the DTD file?

XmlDocument doc = new XmlDocument();
XmlValidatingReader reader = new XmlValidatingReader(new
XmlTextReader(stream));

reader.XmlResolver = new MyDTDResolver();

reader.ValidationType = ValidationType.DTD;

doc.Load(reader);

The XML document's stream is contained in the stream variable

Here is MyDTDResolver declaration:

private class MyDTDResolver:XmlUrlResolver

{

public override object GetEntity(Uri absoluteUri, string role, Type
ofObjectToReturn)

{

return (returns a stream of the local copy of the DTD document that I
validate XML against)

}

}
Nov 12 '05 #1
18 5509


Vlad wrote:
I have the following code:
I have a local copy of the DTD that I need to validate incoming XML
documents against.
The XML document has the <!DOCTYPE myname SYSTEM "myfile.dtd"> define.
When the following code is executed the XML gets resolved through the
XMLResolver and gets correctly validated against the locally stored DTD
file.
The problem occurs when the incoming XML contains no DOCTYPE attribute. The
resolver code never gets called and the validation does not occur at all.
What am I doing wrong here? Is that a bug and there is no way to enforce
the DTD even if the icoming XML file does not specify the DTD file?


It is a known shortcoming of the whole DTD approach that parsers do look
for a DOCTYPE declaration to validate the XML against. I have not
exhaustively looked at the .NET classes to perform DTD validation but it
might well be that you need to run your incoming XML stream through a
filter mirroring all nodes but inserting the DOCTYPE declaration at the
beginning to be able to perform the validation ágainst the DTD.
--

Martin Honnen
http://JavaScript.FAQTs.com/

Nov 12 '05 #2


Vlad wrote:
I have the following code:
I have a local copy of the DTD that I need to validate incoming XML
documents against.
The XML document has the <!DOCTYPE myname SYSTEM "myfile.dtd"> define.
When the following code is executed the XML gets resolved through the
XMLResolver and gets correctly validated against the locally stored DTD
file.
The problem occurs when the incoming XML contains no DOCTYPE attribute. The
resolver code never gets called and the validation does not occur at all.
What am I doing wrong here? Is that a bug and there is no way to enforce
the DTD even if the icoming XML file does not specify the DTD file?


It is a known shortcoming of the whole DTD approach that parsers do look
for a DOCTYPE declaration to validate the XML against. I have not
exhaustively looked at the .NET classes to perform DTD validation but it
might well be that you need to run your incoming XML stream through a
filter mirroring all nodes but inserting the DOCTYPE declaration at the
beginning to be able to perform the validation ágainst the DTD.
--

Martin Honnen
http://JavaScript.FAQTs.com/

Nov 12 '05 #3
Your document has to have DOCTYPE to perform DTD validation. XmlResolver is
being used to resolve external entities, including external DTD of course.
There is not bug here.
Yan

"Vlad" <RE***************@comcast.net> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
I have the following code:
I have a local copy of the DTD that I need to validate incoming XML
documents against.
The XML document has the <!DOCTYPE myname SYSTEM "myfile.dtd"> define.
When the following code is executed the XML gets resolved through the
XMLResolver and gets correctly validated against the locally stored DTD
file.
The problem occurs when the incoming XML contains no DOCTYPE attribute.
The
resolver code never gets called and the validation does not occur at all.
What am I doing wrong here? Is that a bug and there is no way to enforce
the DTD even if the icoming XML file does not specify the DTD file?

XmlDocument doc = new XmlDocument();
XmlValidatingReader reader = new XmlValidatingReader(new
XmlTextReader(stream));

reader.XmlResolver = new MyDTDResolver();

reader.ValidationType = ValidationType.DTD;

doc.Load(reader);

The XML document's stream is contained in the stream variable

Here is MyDTDResolver declaration:

private class MyDTDResolver:XmlUrlResolver

{

public override object GetEntity(Uri absoluteUri, string role, Type
ofObjectToReturn)

{

return (returns a stream of the local copy of the DTD document that I
validate XML against)

}

}

Nov 12 '05 #4
Your document has to have DOCTYPE to perform DTD validation. XmlResolver is
being used to resolve external entities, including external DTD of course.
There is not bug here.
Yan

"Vlad" <RE***************@comcast.net> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
I have the following code:
I have a local copy of the DTD that I need to validate incoming XML
documents against.
The XML document has the <!DOCTYPE myname SYSTEM "myfile.dtd"> define.
When the following code is executed the XML gets resolved through the
XMLResolver and gets correctly validated against the locally stored DTD
file.
The problem occurs when the incoming XML contains no DOCTYPE attribute.
The
resolver code never gets called and the validation does not occur at all.
What am I doing wrong here? Is that a bug and there is no way to enforce
the DTD even if the icoming XML file does not specify the DTD file?

XmlDocument doc = new XmlDocument();
XmlValidatingReader reader = new XmlValidatingReader(new
XmlTextReader(stream));

reader.XmlResolver = new MyDTDResolver();

reader.ValidationType = ValidationType.DTD;

doc.Load(reader);

The XML document's stream is contained in the stream variable

Here is MyDTDResolver declaration:

private class MyDTDResolver:XmlUrlResolver

{

public override object GetEntity(Uri absoluteUri, string role, Type
ofObjectToReturn)

{

return (returns a stream of the local copy of the DTD document that I
validate XML against)

}

}

Nov 12 '05 #5
Vlad wrote:
The problem occurs when the incoming XML contains no DOCTYPE attribute. The
resolver code never gets called and the validation does not occur at all.
What am I doing wrong here? Is that a bug and there is no way to enforce
the DTD even if the icoming XML file does not specify the DTD file?


No Doctype - no validation. You can add Doctype to a document using a
variety of methods. XSLT is the simplest one - the following stylesheet
adds Doctype to a source document, while preserving the rest as is:

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output doctype-system="myfile.dtd"/>
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>

With big documents though it could be quite ineffective so I'd use
custom XmlReader, which exposes synthetic Doctype node if the document
doesn't have one.

--
Oleg Tkachenko [XML MVP]
http://blog.tkachenko.com
Nov 12 '05 #6
Vlad wrote:
The problem occurs when the incoming XML contains no DOCTYPE attribute. The
resolver code never gets called and the validation does not occur at all.
What am I doing wrong here? Is that a bug and there is no way to enforce
the DTD even if the icoming XML file does not specify the DTD file?


No Doctype - no validation. You can add Doctype to a document using a
variety of methods. XSLT is the simplest one - the following stylesheet
adds Doctype to a source document, while preserving the rest as is:

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output doctype-system="myfile.dtd"/>
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>

With big documents though it could be quite ineffective so I'd use
custom XmlReader, which exposes synthetic Doctype node if the document
doesn't have one.

--
Oleg Tkachenko [XML MVP]
http://blog.tkachenko.com
Nov 12 '05 #7
That defeats the purpose of the ValidatingReader and makes it useless since
I have no control over the incoming files. That means that someone could
just submit an XML file without a DOCTYPE and render the whole validation
process useless.
As far as using the XSLT code to insert the DOCTYPE, I couldn't use it
because the XML files that I receive could be very large and I do not want
to regenerate the whole file just to check for its validity.
As for creating a custom XmlReader, I initially tried it but it is not that
simple since in order to fake the DOCTYPE attribute one has to first
determine that it is missing or invalid and then simulate it only in that
case. Do you have any code that could do it?

Here is what I ended up doing:
Because the ValidatingReader does not throw any exceptions if DOCTYPE is
missing I just check XmlDocument.DocumentType property after the document
has been read in. If it is null-I reject the file as if it has failed the
validation. It is unfortunate, since the file might actually be fully
compatible with the DTD except for the missing DOCTYPE attribute.
If you have a sample code for the custom XmlReader or any other workaround
that would ensure that the missing DOCTYPE does not effect the
ValidatingReader functionality I would really appreciate it.
Thank you!

"Oleg Tkachenko [MVP]" <oleg@NO!SPAM!PLEASEtkachenko.com> wrote in message
news:el**************@TK2MSFTNGP09.phx.gbl...
Vlad wrote:
The problem occurs when the incoming XML contains no DOCTYPE attribute. The resolver code never gets called and the validation does not occur at all. What am I doing wrong here? Is that a bug and there is no way to enforce the DTD even if the icoming XML file does not specify the DTD file?


No Doctype - no validation. You can add Doctype to a document using a
variety of methods. XSLT is the simplest one - the following stylesheet
adds Doctype to a source document, while preserving the rest as is:

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output doctype-system="myfile.dtd"/>
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>

With big documents though it could be quite ineffective so I'd use
custom XmlReader, which exposes synthetic Doctype node if the document
doesn't have one.

--
Oleg Tkachenko [XML MVP]
http://blog.tkachenko.com

Nov 12 '05 #8
That defeats the purpose of the ValidatingReader and makes it useless since
I have no control over the incoming files. That means that someone could
just submit an XML file without a DOCTYPE and render the whole validation
process useless.
As far as using the XSLT code to insert the DOCTYPE, I couldn't use it
because the XML files that I receive could be very large and I do not want
to regenerate the whole file just to check for its validity.
As for creating a custom XmlReader, I initially tried it but it is not that
simple since in order to fake the DOCTYPE attribute one has to first
determine that it is missing or invalid and then simulate it only in that
case. Do you have any code that could do it?

Here is what I ended up doing:
Because the ValidatingReader does not throw any exceptions if DOCTYPE is
missing I just check XmlDocument.DocumentType property after the document
has been read in. If it is null-I reject the file as if it has failed the
validation. It is unfortunate, since the file might actually be fully
compatible with the DTD except for the missing DOCTYPE attribute.
If you have a sample code for the custom XmlReader or any other workaround
that would ensure that the missing DOCTYPE does not effect the
ValidatingReader functionality I would really appreciate it.
Thank you!

"Oleg Tkachenko [MVP]" <oleg@NO!SPAM!PLEASEtkachenko.com> wrote in message
news:el**************@TK2MSFTNGP09.phx.gbl...
Vlad wrote:
The problem occurs when the incoming XML contains no DOCTYPE attribute. The resolver code never gets called and the validation does not occur at all. What am I doing wrong here? Is that a bug and there is no way to enforce the DTD even if the icoming XML file does not specify the DTD file?


No Doctype - no validation. You can add Doctype to a document using a
variety of methods. XSLT is the simplest one - the following stylesheet
adds Doctype to a source document, while preserving the rest as is:

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output doctype-system="myfile.dtd"/>
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>

With big documents though it could be quite ineffective so I'd use
custom XmlReader, which exposes synthetic Doctype node if the document
doesn't have one.

--
Oleg Tkachenko [XML MVP]
http://blog.tkachenko.com

Nov 12 '05 #9
Hi Vlad,

Based on my experience, I think you can first check the DocumentType
property of XmlDocument. If it is null, you can add a <DOCTYPE> node into
the document using XSLT and validate the XmlDocument. Although it might hit
performance when the XML file is very big, it's better than reject the file
which might be valid.

HTH.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

Nov 12 '05 #10
Hi Vlad,

Based on my experience, I think you can first check the DocumentType
property of XmlDocument. If it is null, you can add a <DOCTYPE> node into
the document using XSLT and validate the XmlDocument. Although it might hit
performance when the XML file is very big, it's better than reject the file
which might be valid.

HTH.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

Nov 12 '05 #11
While it's an interesting idea to check the file twice in case the
DocumentType is null I would rather see if there is any other way to do it.
As was seen in Oleg's reply the custom validator could be one of the
solutions since the XSLT would give me a substantial performance hit for
large files (which I get a lot of). Do you have any sample custom reader
code that might create a DOCTYPE if one is not present?.

However MS documentation does not specify that the XML documents MUST have
DOCTYPE or ValidatingReader won't validate. Because of that I would like to
see MS actually provide some workaround for this issue.

Thanks a lot,
--
Vlad
P.S. Please remove "REMOVETHIS" from my email address to reply...
"Kevin Yu [MSFT]" <v-****@online.microsoft.com> wrote in message
news:fK**************@cpmsftngxa10.phx.gbl...
Hi Vlad,

Based on my experience, I think you can first check the DocumentType
property of XmlDocument. If it is null, you can add a <DOCTYPE> node into
the document using XSLT and validate the XmlDocument. Although it might hit performance when the XML file is very big, it's better than reject the file which might be valid.

HTH.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

Nov 12 '05 #12
While it's an interesting idea to check the file twice in case the
DocumentType is null I would rather see if there is any other way to do it.
As was seen in Oleg's reply the custom validator could be one of the
solutions since the XSLT would give me a substantial performance hit for
large files (which I get a lot of). Do you have any sample custom reader
code that might create a DOCTYPE if one is not present?.

However MS documentation does not specify that the XML documents MUST have
DOCTYPE or ValidatingReader won't validate. Because of that I would like to
see MS actually provide some workaround for this issue.

Thanks a lot,
--
Vlad
P.S. Please remove "REMOVETHIS" from my email address to reply...
"Kevin Yu [MSFT]" <v-****@online.microsoft.com> wrote in message
news:fK**************@cpmsftngxa10.phx.gbl...
Hi Vlad,

Based on my experience, I think you can first check the DocumentType
property of XmlDocument. If it is null, you can add a <DOCTYPE> node into
the document using XSLT and validate the XmlDocument. Although it might hit performance when the XML file is very big, it's better than reject the file which might be valid.

HTH.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

Nov 12 '05 #13
Vlad wrote:
While it's an interesting idea to check the file twice in case the
DocumentType is null I would rather see if there is any other way to do it.
As was seen in Oleg's reply the custom validator could be one of the
solutions since the XSLT would give me a substantial performance hit for
large files (which I get a lot of). Do you have any sample custom reader
code that might create a DOCTYPE if one is not present?.


You know, actually I'm not sure if it works. The problem is in tight
coupling between XmlValidatingReader and XmlTextReader -
XmlValidatingReader requires XmlTextReader as input reader (which is a
well known bug). That's not a problem - you can extend XmlTextReader to
expose synthetic Doctype. The problem is that XmlValidatingReader asks
XmlTextReader for Doctype via *internal* property of XmlTextReader. I
don't see how it can be worked around.
Another alternative would be adding Doctype while passing XML through
XmlReader-XmlWriter pipe. This whay you can modify document in a
streaming way - without loading it into memory as a whole (XmlDocument
or XSLT approach). Something like this:

XmlReader r = new XmlTextReader("foo.xml");
XmlWriter w = new XmlTextWriter("foo2.xml", Encoding.UTF8);
bool hasDoctype = false, inProlog = true;
while (r.Read())
{
if (r.NodeType == XmlNodeType.DocumentType)
hasDoctype = true;
else if (inProlog && !hasDoctype && r.NodeType ==
XmlNodeType.Element)
{
//First element is about to be written - insert Doctype here
w.WriteDocType(r.Name, null, "foo.dtd", null);
inProlog = false;
}
w.WriteNode(r, false);
}
r.Close();
w.Close();
XmlValidatingReader vr = new XmlValidatingReader(new
XmlTextReader("foo2.xml"));
while (vr.Read());

--
Oleg Tkachenko [XML MVP]
http://blog.tkachenko.com
Nov 12 '05 #14
Vlad wrote:
While it's an interesting idea to check the file twice in case the
DocumentType is null I would rather see if there is any other way to do it.
As was seen in Oleg's reply the custom validator could be one of the
solutions since the XSLT would give me a substantial performance hit for
large files (which I get a lot of). Do you have any sample custom reader
code that might create a DOCTYPE if one is not present?.


You know, actually I'm not sure if it works. The problem is in tight
coupling between XmlValidatingReader and XmlTextReader -
XmlValidatingReader requires XmlTextReader as input reader (which is a
well known bug). That's not a problem - you can extend XmlTextReader to
expose synthetic Doctype. The problem is that XmlValidatingReader asks
XmlTextReader for Doctype via *internal* property of XmlTextReader. I
don't see how it can be worked around.
Another alternative would be adding Doctype while passing XML through
XmlReader-XmlWriter pipe. This whay you can modify document in a
streaming way - without loading it into memory as a whole (XmlDocument
or XSLT approach). Something like this:

XmlReader r = new XmlTextReader("foo.xml");
XmlWriter w = new XmlTextWriter("foo2.xml", Encoding.UTF8);
bool hasDoctype = false, inProlog = true;
while (r.Read())
{
if (r.NodeType == XmlNodeType.DocumentType)
hasDoctype = true;
else if (inProlog && !hasDoctype && r.NodeType ==
XmlNodeType.Element)
{
//First element is about to be written - insert Doctype here
w.WriteDocType(r.Name, null, "foo.dtd", null);
inProlog = false;
}
w.WriteNode(r, false);
}
r.Close();
w.Close();
XmlValidatingReader vr = new XmlValidatingReader(new
XmlTextReader("foo2.xml"));
while (vr.Read());

--
Oleg Tkachenko [XML MVP]
http://blog.tkachenko.com
Nov 12 '05 #15
Thanks Oleg for your suggestion. There is still a permance hit though
because I still have read the whole source file into a new file before
reading the new file again using the validating reader.
I guess I could change your code to generate the new file in memory using a
MemoryStream that might improve the performace somewhat but the main theme
stays the same--double processing.
Still... I wish MS would list this as a bug and fix this.
Thanks!

"Oleg Tkachenko [MVP]" <oleg@NO!SPAM!PLEASEtkachenko.com> wrote in message
news:#B**************@TK2MSFTNGP09.phx.gbl...
Vlad wrote:
While it's an interesting idea to check the file twice in case the
DocumentType is null I would rather see if there is any other way to do it. As was seen in Oleg's reply the custom validator could be one of the
solutions since the XSLT would give me a substantial performance hit for
large files (which I get a lot of). Do you have any sample custom reader code that might create a DOCTYPE if one is not present?.


You know, actually I'm not sure if it works. The problem is in tight
coupling between XmlValidatingReader and XmlTextReader -
XmlValidatingReader requires XmlTextReader as input reader (which is a
well known bug). That's not a problem - you can extend XmlTextReader to
expose synthetic Doctype. The problem is that XmlValidatingReader asks
XmlTextReader for Doctype via *internal* property of XmlTextReader. I
don't see how it can be worked around.
Another alternative would be adding Doctype while passing XML through
XmlReader-XmlWriter pipe. This whay you can modify document in a
streaming way - without loading it into memory as a whole (XmlDocument
or XSLT approach). Something like this:

XmlReader r = new XmlTextReader("foo.xml");
XmlWriter w = new XmlTextWriter("foo2.xml", Encoding.UTF8);
bool hasDoctype = false, inProlog = true;
while (r.Read())
{
if (r.NodeType == XmlNodeType.DocumentType)
hasDoctype = true;
else if (inProlog && !hasDoctype && r.NodeType ==
XmlNodeType.Element)
{
//First element is about to be written - insert Doctype here
w.WriteDocType(r.Name, null, "foo.dtd", null);
inProlog = false;
}
w.WriteNode(r, false);
}
r.Close();
w.Close();
XmlValidatingReader vr = new XmlValidatingReader(new
XmlTextReader("foo2.xml"));
while (vr.Read());

--
Oleg Tkachenko [XML MVP]
http://blog.tkachenko.com

Nov 12 '05 #16
Thanks Oleg for your suggestion. There is still a permance hit though
because I still have read the whole source file into a new file before
reading the new file again using the validating reader.
I guess I could change your code to generate the new file in memory using a
MemoryStream that might improve the performace somewhat but the main theme
stays the same--double processing.
Still... I wish MS would list this as a bug and fix this.
Thanks!

"Oleg Tkachenko [MVP]" <oleg@NO!SPAM!PLEASEtkachenko.com> wrote in message
news:#B**************@TK2MSFTNGP09.phx.gbl...
Vlad wrote:
While it's an interesting idea to check the file twice in case the
DocumentType is null I would rather see if there is any other way to do it. As was seen in Oleg's reply the custom validator could be one of the
solutions since the XSLT would give me a substantial performance hit for
large files (which I get a lot of). Do you have any sample custom reader code that might create a DOCTYPE if one is not present?.


You know, actually I'm not sure if it works. The problem is in tight
coupling between XmlValidatingReader and XmlTextReader -
XmlValidatingReader requires XmlTextReader as input reader (which is a
well known bug). That's not a problem - you can extend XmlTextReader to
expose synthetic Doctype. The problem is that XmlValidatingReader asks
XmlTextReader for Doctype via *internal* property of XmlTextReader. I
don't see how it can be worked around.
Another alternative would be adding Doctype while passing XML through
XmlReader-XmlWriter pipe. This whay you can modify document in a
streaming way - without loading it into memory as a whole (XmlDocument
or XSLT approach). Something like this:

XmlReader r = new XmlTextReader("foo.xml");
XmlWriter w = new XmlTextWriter("foo2.xml", Encoding.UTF8);
bool hasDoctype = false, inProlog = true;
while (r.Read())
{
if (r.NodeType == XmlNodeType.DocumentType)
hasDoctype = true;
else if (inProlog && !hasDoctype && r.NodeType ==
XmlNodeType.Element)
{
//First element is about to be written - insert Doctype here
w.WriteDocType(r.Name, null, "foo.dtd", null);
inProlog = false;
}
w.WriteNode(r, false);
}
r.Close();
w.Close();
XmlValidatingReader vr = new XmlValidatingReader(new
XmlTextReader("foo2.xml"));
while (vr.Read());

--
Oleg Tkachenko [XML MVP]
http://blog.tkachenko.com

Nov 12 '05 #17
Vlad wrote:
Thanks Oleg for your suggestion. There is still a permance hit though
because I still have read the whole source file into a new file before
reading the new file again using the validating reader.
I guess I could change your code to generate the new file in memory using a
MemoryStream that might improve the performace somewhat but the main theme
stays the same--double processing.


Yeah, MemoryStream or file or whatever appropriate for your application,
but unfortunately I don't see how you can avoid this step.

--
Oleg Tkachenko [XML MVP]
http://blog.tkachenko.com
Nov 12 '05 #18
Vlad wrote:
Thanks Oleg for your suggestion. There is still a permance hit though
because I still have read the whole source file into a new file before
reading the new file again using the validating reader.
I guess I could change your code to generate the new file in memory using a
MemoryStream that might improve the performace somewhat but the main theme
stays the same--double processing.


Yeah, MemoryStream or file or whatever appropriate for your application,
but unfortunately I don't see how you can avoid this step.

--
Oleg Tkachenko [XML MVP]
http://blog.tkachenko.com
Nov 12 '05 #19

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: Larry | last post by:
I believe the .Net XmlValidatingReader should fail when validating XML that contains a ComplexType element with white space when the ComplexType element has the mixed attribute set to false in the...
4
by: Jesse Elve | last post by:
I am using an XmlValidatingReader which uses an XSD for xml validation. The code has been performing reliably for months. Yesterday it failed for the first time with the following exception: ...
3
by: Nuevo Registrado | last post by:
All, I am having a tough time figuring out how to code a simple app to read an xml file and an xsd file and validate the xml file using the xsd without using a namespace for the schema. Help?...
1
by: George W. | last post by:
When attempting to validate an XML file, If the file is valid, it validates correctly, and it will catch most ValidationEvents without problem. However, I keep getting the following Exception:...
9
by: jason | last post by:
how do you use the XmlValidatingReader to validate an XML document that is passed into the XmlValidatingReader constructor? it looks like the normal process is to use an underlying reader, as...
6
by: SHC | last post by:
Hi all, I created an application from the Console Application (.NET) of VC++ .NET 2003, and I did "Build" the application of the attached .cpp file, volcanoes.xml and geology.dtd on my VC++ .NET...
5
by: Geoff | last post by:
I am using an XMLValidatingReader to validate an XML file received via a web service. I want to verify that the incoming file matches the XML schema. When testing the validation routine, the...
1
by: Bernhard Felkel | last post by:
I have troubles validating XML files with key/keyref constraints. Here´s my schema: <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"...
1
by: Plop69 | last post by:
need some help on following: xml file 1 <TEST xmlns="http://test" > <OK>mlkddflmkj</OK> </TEST> xml file 2
12
by: Plop69 | last post by:
need some help on following: xml file 1 <TEST xmlns="http://test" > <OK>mlkddflmkj</OK> </TEST>
0
by: veera ravala | last post by:
ServiceNow is a powerful cloud-based platform that offers a wide range of services to help organizations manage their workflows, operations, and IT services more efficiently. At its core, ServiceNow...
0
by: VivesProcSPL | last post by:
Obviously, one of the original purposes of SQL is to make data query processing easy. The language uses many English-like terms and syntax in an effort to make it easy to learn, particularly for...
3
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 3 Jan 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). For other local times, please check World Time Buddy In...
0
by: mar23 | last post by:
Here's the situation. I have a form called frmDiceInventory with subform called subfrmDice. The subform's control source is linked to a query called qryDiceInventory. I've been trying to pick up the...
2
by: jimatqsi | last post by:
The boss wants the word "CONFIDENTIAL" overlaying certain reports. He wants it large, slanted across the page, on every page, very light gray, outlined letters, not block letters. I thought Word Art...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: fareedcanada | last post by:
Hello I am trying to split number on their count. suppose i have 121314151617 (12cnt) then number should be split like 12,13,14,15,16,17 and if 11314151617 (11cnt) then should be split like...
1
by: davi5007 | last post by:
Hi, Basically, I am trying to automate a field named TraceabilityNo into a web page from an access form. I've got the serial held in the variable strSearchString. How can I get this into the...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.