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" <[EMAIL PROTECTED]> To: "Ivelin Ivanov" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
