Lists Home |
Date Index |
Because an XML Schema by definition implies
a system based on it. XML is just data until
it encounters a schema. After that, the data
is augmented with information that the original
XML instance did not specify to enable processing
the instance also did not specify. If you need an
answer to your question, it is in the post-parse
It isn't a bad thing. It is a processing system
choice. XML in and of itself does not have a
post-parse processing model. Those who want such
things are doing the job of writing XML system
specifications. Because XML itself does not
have that as a core definition, lots of choices
become available and none are right or wrong;
just more or less feature-rich given the results
Why do some object? Like you, they are writing
their own code for the post-parse processing and
don't desire core XML specifications that force
any requirements past the initial parse.
Dr. Goldfarb used to tell me, "everyone wants
to own the parse" and meant, the rules for how
to process it's output, that is, the first
intepretation. Semiotics teaches that it is not
bad to have a strictly defined interpretation but
that there will be many and each contextually dependant.
XML enables that. Some are not happy about it.
Defining the context or semantic is THE problem.
The XML is trivial if you get past "Who gets to
name the names".
The problem is, that means, as said elsewhere,
that simply requiring XML support doesn't require
much and that to guarantee results, one has to be
more specific to be interoperable. Therefore,
2. ANI/ALI packet support per NENA specification with
The NENA committee starts with 1. The application
language implementor starts with two. Two may
require datatype support or at least a rigorous
specification of the datatypes to be expected.
It might not.
From: Gustaf Liljegren [mailto:email@example.com]
Ever since XML Schema started to evolve and the talk about datatypes in XML
took off, I've been wondering secretly why XML validation needs the concept
of datatypes at all. XML is a plain text format, so content validation in
XML should be no different from regular pattern matching. Or why should it?
A string of three digits may be numeric to an application, but stored or
transmitted in XML, it's still just three characaters of plain text. If my
application wants an integer, all I'd do would be to check if all
characters are in the range 0-9. Regular expressions would be enough for
that. If possible, I'd have this check written in the schema, or some
special module of patterns attached to the schema.