cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <ive...@apache.org>
Subject Re: form handling session
Date Fri, 05 Apr 2002 13:38:57 GMT
Torsten,

Since Daniel requested, I'll take the discussion back in the list, or at
least the email part of it.
If someone wants a copy of our ICQ discussion, I can send offilne.

----- Original Message -----
From: "Torsten Curdt" <tcurdt@dff.st>
To: "Ivelin Ivanov" <ivelin@apache.org>
Sent: Thursday, April 04, 2002 2:33 AM
Subject: Re: form handling session


> > > > you would do:
> > >  > <rule context="/">
> > >  >  <report test="count(bla) <= 5 and count(bla) > 2"
> > >
> > > ah... yes
> > >
> > > well, you would need extract this from the expression. (ugly and no
> > > piece of cake) ...but it's there :-/
> >
> > Really, really hard. Sch was not intended for reverse engineering.
>
> well, I wouldn't call this reverse engineering... it's actually is node
> applicable regarding to this schema(tron) or not... actually an easy
> question and a fullblown schema should be able to provide this...

As I said in ICQ, we should cut this out from the first release.
Will take me more time to implement than everything I've checked in so far.

> > XPath is broken down into a tree of predicates. Making a data
enumeration
> > out of the tree is just crazy.
> > Its goal is to allow powerful rules over any subset of elements.
> > With Sch one can express everything that grammar schemas can (RelaxNG,
XSD,
> > DTD) and a lot more.
> > However with grammars its easier to describe document structure, even
though
> > they lack expressive power.
>
> :-/
>
> don't know if one can simplify this... you would need to now which rules
> are structural rules and which are textual. I don't like that there is no
> distinction in schematron :-(

Power vs simplicity.

> > > that's why I prefer markup :-)
> >
> > Ideally we would make use of combos like (XSD + embedded Schematron) and
> > (RelaxNG + Sch).
> > Both combos have been implemented by others already, although I don't
think
> > they're readyly pluggable for our API.
> >
> > R+Sch
> > http://www.sun.com/software/xml/developers/schematronaddon/
> >
> > XSD+Sch:
> > http://lists.w3.org/Archives/Public/xmlschema-dev/2001Oct/0242.html
>
> I'll have a look....
>
> > >  > Why isValidNode critical ? I didn't need that for Sch validation.If
an
> > >  > XPath is invalid, i.e. points to a node in the bean which isn't
> > > there, > JXPath will throw exception.
> > >
> > > Hm... I guess this is more a matter of design... the preceptor should
> > > know this (because that's exactly his job - knowing the structure of
an
> > > valid XML document) If you use JXPath for this you ask the *instance*
> > > about this... that's a design flaw. This will work for beans but not
for
> > > DOMs. The problem are optional values. In a bean optional values are
> > > always there (because the class is a static structure) so if you ask
"is
> > > /root/bla valid" you will get a "yes" because the node is always there
> > > (although it's optional). This is not true for a DOM. Since this node
is
> > > optional it might not be there since a DOM is dynamic - so how do you
> > > know if a node is valid when you ask the instance - it might be
optional
> > > and not yet there...
> > >
> > > see... so how can we get around this one then? :-(
> >
> > I see your point.
> > Remember though, that even with XSD and Relax, you're not required to
define
> > all the structures and elements in a document. XSD specificly can be
used to
> > define a set of types, applied against some elements in any document
which
> > refer to that type. SOAPs schema header is a good example of this usage.
Of
> > course in XSD you can describe the root element and all the others under
it,
> > but this is by far not the only way people use it.
>
> sorry... AFAIIK both relax and xsd both specify the whole document
> structure. You can of course have complex types that source out some of
> the document verbosity. But that's (very simplified) some sort of
> including mechanism...


That's correct. But if you pass to XSD a set of DOM nodes which are parts of
a bigger document,
then you can achieve partial validation.

>
> > So I think that isValidNode() is a nice idea, but it is not universally
> > applicable.
> > We should either drop it (my preference) or at least not require that
its
> > implemented.
>
> it's necessary for all DOMs... as I stated above...

I understand the extra validation value of this, but it's not possible to
implement
for JavaBeans (because of circular references). Also in many scenarios we
will not be validating
the whole document, but rather pieces of it, so enumerating all valid XPaths
for a document maybe unnecessary overhead.
We'll need to drop it from the first round of the interface, until we
understand better its value.

> > > BTW: what's the difference between "report" and "assert"?
> >
> > Trivial.
> > <report test="A"/> is exactly the same as <assert test="not(A)"/>
> > I am not convinced of the value of report. Just extra sugar.
>
> oh... that's easy
>
> > > We have another (kinda) related problem:
> > >
> > > in the Preceptor interface we have:
> > >
> > >    public Collection validate(Instance instance, Context context)
throws
> > > InvalidXPathSyntaxException;
> > >
> > > how can we know what nodes (=xpaths) we are supposed to validate for
the
> > > whole document? The instance does not yet expose this information.
(this
> > > is because we move the validation from the instance into the
preceptor)
> >
> > When phase is not specified, Sch requires that all <patterns> are
applied.
> > That's how my impl works.
> >
> > If I don't read your question wrong, XSD and Relax normally work against
the
> > whole document.
>
> true... but that's what we want to change, right?
>
> > I don't really see this to be a problem.
>
> I do :(

Since Phase is integrated in Schematron, we don't need to worry about other
schemas yet.
The validate(Instance, String Phase) method is sufficient for now.

>
> > I am still confused though, where do you get the Context and why pass it
to
> > the Preceptor.
> > Is it absolutely necessary?
>
> yes... it's only for extensibility... it can be null if you don't need it
> we require i18n support... that's essential for us...

Ok, I see.
How do you typicly do i18n aware validation ?


BTW, we're about to miss our end of week milestone and we still haven't
agreed completely on the API.

What do you suggest we do to avoid this?

Ivelin


> --
> Torsten
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message