Why do we need XML Schemas other than for automatic validation?

[Water Cooler v2]

Sorry for asking this beginner question.

I've written DTDs so far and read about XML Schemas. I understand that
they are a replacement of the DTD fundamentally, and therefore allow
for the validation of an XML document.

My question really is:

Why do we need XML Schemas other than for validation of an XML
document? I am more interested in knowing if already available
"common" XML tools such as the MSXML parser, or DOM Level 3
implementations in today's browsers can do something like:

a) read an XML Schema;
b) then, read the XML document that is defined in the schema;
c) ?? magic ?? read some translation rules (an XSLT file?) that says,
for instance, that <xs:element name="foo" type="xs:string" /> 's value
must go to the column "bar" of this SQL Server database, etc., etc.

So, my question really is, can the available XML tools in the market
from major vendors read an XML Schema, and then not simply validate an
XML document but also read some translation rules from an XSLT file
and do the transformation without a developer having to write any
bespoke application on his part, if he just writes the XML, XSD and
XSLT sheet?

 

[Joseph J. Kesselman]

a) read an XML Schema;

b) then, read the XML document that is defined in the schema;
c) ?? magic ?? read some translation rules (an XSLT file?) that says,
for instance, that <xs:element name="foo" type="xs:string" /> 's value
must go to the column "bar" of this SQL Server database, etc., etc.

Websearch for "XML data binding"

 

[Peter Flynn]

Sorry for asking this beginner question.

I've written DTDs so far and read about XML Schemas. I understand that
they are a replacement of the DTD fundamentally, and therefore allow
for the validation of an XML document.

More of an enhancement to the functionality (with some exceptions).

My question really is:

Why do we need XML Schemas other than for validation of an XML
document?

A schema lets you specify much finer validation criteria (eg "this
element or attribute must contain values in date format" or "this
element or attribute can only have numeric values between 42 and 69" or
whatever). You can't do that in a DTD.

If you don't need this kind of data validation, a DTD may be all you
need. Typically, conventional text publishing applications don't need
it, although IMHO many of them would benefit from it (date and document
control being two obvious areas).

I am more interested in knowing if already available
"common" XML tools such as the MSXML parser, or DOM Level 3
implementations in today's browsers can do something like:

I rarely encounter either of these, so I can't speak for them.
Browser implementation of XML is generally very poor.

a) read an XML Schema;
b) then, read the XML document that is defined in the schema;
c) ?? magic ?? read some translation rules (an XSLT file?) that says,
for instance, that <xs:element name="foo" type="xs:string" /> 's
value must go to the column "bar" of this SQL Server database, etc.,

That process is pretty conventional elsewhere, up to your last line: an
XSLT processor like Saxon, for example, can read the Schema or DTD,
process the document and apply an XSLT file, and specify what to output
when <foo>bar</foo> is encountered (XSLT being a declarative language,
not a procedural one). The output from XSLT itself is normally some
other XML format, or [old] HTML, or just text (but including formats
expressed in text, such as LaTeX, or a control file or data file). To go
further and bind such output functions to an external process like an
SQL server needs additional layers of software.

So, my question really is, can the available XML tools in the market
from major vendors read an XML Schema, and then not simply validate an
XML document but also read some translation rules from an XSLT file
and do the transformation without a developer having to write any
bespoke application on his part, if he just writes the XML, XSD and
XSLT sheet?

Yes, but XSLT itself stops at the point where it creates the output file
or stream. To push that output into another process requires a binding
to that process, which may or may not be included in a specific tool.

And in general this whole procedure is not usually a single monolithic
program, but a set of linked components (parser, validator, editor, API,
monitor, logger, transformer, output bindings, responder, etc). But
depending on the way it is marketed, a given tool may be wrapped so that
it *looks* like a monolith

///Peter

 

[Andy Dingley]

Sorry for asking this beginner question.

I've written DTDs so far and read about XML Schemas. I understand that
they are a replacement of the DTD fundamentally, and therefore allow
for the validation of an XML document.

Why do we need XML Schemas other than for validation of an XML
document?

* Schema is itself an XML document, so it's automatically processable,
in a way that DTDs aren't

* Schema does data typing

* Schema is an XML document, so you can use namespacing to extend it
and add other sorts of descriptive information beyond the usual
structure and type. Look at the web services world, SOAP, WSDL, EAI

* Schema is the starting point for RDFS, OWL and all the SemWeb stuff.
You can not only specify structure to allow a "valid yes/no" test,
but you can start to _communicate_ information, such as communicable
semantics.