You answered my question close enough. My point was, it seems like there
are two major things a validator does:
1) Validation for conformancy to the schema, which involves checking to see
if an element is allowed in a given context, lexical validation, etc.
Validation doesn't necessarily need to be run by all processing tools. For
instance, an XSLT processor doesn't need to do validation except as a
defensive step.
2) Knowing what data type an attribute or an element is, entity expansions,
whitespace handling, etc... the things needed for run-time consumers of the
XML for presentation or general processing. Since these things effect the
semantics of the XML, this type of processing is needed by any consumer
that's going to do generic presentation or generic processing.
I was just wondering if it makes any sense to be able to use (2) without
(1). From what you are saying, the answer is no, or, at least, it's not in
the cards at the moment.
-scott
[EMAIL PROTECTED]
.com To: [EMAIL PROTECTED]
cc: (bcc: Scott Boag/CAM/Lotus)
01/14/00 Subject: Re: Validator
01:27 PM
Please
respond to
xerces-dev
I'm not sure if I know exactly what you mean by the terminology you are
using. So I might not still exactly answer your questions.... but:
The validators do both of those things. The validators are the pools for
all of the element, attribute, etc... declarations. So the validator is who
you talk to if you just want to explore that stuff (until such a time as it
is available via the DOM.) And they are the means of validation. At least
in the C++ version, you can ask for an enumerator for the element pool for
instance, and look through the defined elements, and poke around in their
content models, if that's what you are refering to by 'type discovery'.
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
"Scott Boag/CAM/Lotus" <[EMAIL PROTECTED]> on 01/13/2000 06:12:36 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: Re: Validator
Thanks, but I don't think you answered my question, "Is there a difference
between validation and schema processing??". i.e. it seems like validation
is a superset of type discovery and perhaps some other functions needed by
XML & DOM consumers.
-scott
[EMAIL PROTECTED]
.com To: [EMAIL PROTECTED]
cc: (bcc: Scott
Boag/CAM/Lotus)
01/13/00 Subject: Re: Validator
08:39 PM
Please
respond to
xerces-dev
We made a choice long ago that supporting validation of a result tree in
place falls into the 'too hard' category, because we have to structure our
validators to optimize validation of a streaming model. So the validators
are designed to validate in a streaming way.
However, having said that, it would not be too hard to either:
1) Do the 'restreaming' that I indicated before. YOu would have to create a
DOMInputsource and a DOMInputStream, or some such names, which would stream
the data back in from the DOM tree through the parser.
OR
2) You could just get direct access to the validator and call the validator
calls. If the DOM tree does not store element ids, then you will have to
relook up the elements and attributes in the validator's pools, in order to
get the numbers that the validator requires in order to validate, but
that's still probably faster than #1.
BUT, #1 does what it does purely in terms of some pretty standard APIs, and
would probably be pretty portable as a 'restreaming' mechanism. #2 would
depend upon you talking to Xerces specific validator interfaces, though it
would be faster. So I guess its a 'you make the call' as to which is more
important to you.
But this all still allows the core validation architecture to remain stream
oriented and to be optimized to do its 'lookaside' style of validation as
the XML is flowing through the parser system.
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
"Scott Boag/CAM/Lotus" <[EMAIL PROTECTED]> on 01/13/2000 05:26:54 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: xalan-dev@xml.apache.org
Subject: Re: Validator
> What if I want to validate the result of an Xalan transform? Do I have
> to stream it to disk?
Damn good point. It would really be nice to have an on-the-fly validation
of the result tree.
I haven't really been keeping up on the work for schemas in Xerces. Is
there a difference between validation and schema processing?? Eventually,
Xalan & associated formatters will need to process schemas for both the
input and the output trees without XML being involved. For input so that
it can support future XSLT type matching, and for the output so that
formatters can handle type manipulation.
-scott
Paul Prescod
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
.net> cc: (bcc: Scott
Boag/CAM/Lotus)
Subject: Re: Validator
01/13/00
07:55 PM
Please
respond to
xerces-dev
Is it really the case that the protocol between parser and validator
could become a huge performance drain?
I would have expected it to be a quiet conversation in comparison to the
noise of Unicode character lookups, URL fetches, lexical analysis,
well-formedness checking, and so forth. My experience is that the best
XML parsers often work at IO speeds (at least on my computer) so there
is probably time to spare for a little abstraction and code reuse.
What if I want to validate the result of an Xalan transform? Do I have
to stream it to disk?
--
Paul Prescod - ISOGEN Consulting Engineer speaking for himself
"Remember, Ginger Rogers did everything that Fred Astaire did,
but she did it backwards and in high heels."
--Faith Whittlesey
