Michael,
You're getting into XMLForm internals pretty fast.
Hope others can get into it at the same pace.
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 16, 2002 4:20 PM
Subject: Re: [Announcement] XMLForm 0.8.2 released
>
> Hello,
>
> Let's say I have an instance data node called MOTHERS_STREET_ADDRESS. I
want to
> create a constraint that says these characters are illegal: ^ # *( ), but
these
> are ok . (period) @ &. The xf:caption of the xf:textbox is "Street"
>
> I would like to write rule that looks like:
> <rule context="/MOTHERS_STREET_ADDRESS">
> <assert><value-of select="xf:caption"/> contains an illegal
> character.</assert>
> </rule>
>
> AFAIK, "normal" Schematron implementation would produce "Street contains
an
> illegal character." But XMLForm is vaidating against the data model, not
the
> form description, so there is no <xf:caption> child to get the <value-of>.
I don't think "normal" Schematron will evaluate the assert above any
different then our implementation.
Schematron only evaluates the "test" attribute argument and not the content.
BTW, did you intentionally leave the assert without a test argument?
>
> I thought this was big problem last night at 2:30 AM, but now I think I
just
> need to get more sleep :-) Why not assert "contains an illegal
character" and
> have some downstream xslt "violation template" append the proper
<xf:caption>,
> or whatever else is needed . Duh! Of course, each UI widget might have
to
> invoke a different violation template...
Or you can have "michael-assert-variables" namespace tags in the assert
rules.
Then you can write a few xslt templates rendering your namespace tags and
pass all violations through these templates.
I gave an example in my previous email.
>
> A lesser problem: I want a more detailed message than "contains an
illegal
> character." This message leaves the user wondering "which character is
> illegal?" Period? Ampersand?, Number-sign (#)?. I wish there were a way
to
> produce:
> Street cannot contain a "#" or "Street cannot contain a "^"; or
Street
> cannot contain a "(" etc.
> without resorting to:
> <assert test="not(contains(.,'*')">Street cannot contain an asterisk
> (*)</assert>
> <assert test="not(contains(.,'^')">Street cannot conatain a caret
> (^)</assert>
> <assert test="not(contains(.,'(')">Street cannot contain a
parenthesis "
> ("</assert>...etc.
> which would become very tedious with a large number of exceptions.
>
> But this is maybe asking too much of Schematron?
I am not aware of a better solution, but I'd recommend that you post this
question on the Schematron list.
Folks are pretty responsive there.
>
> <snip>
> >If we make ai18n-enabled form then this approach can be a problem as we
> >should have translations for all the possible cases and values. Haven't
yet
> >time to investigate the possibilities better, but I think that one can
use
> >dictionary keys instead of a real message, e.g.:
>
> ><rule context="/email">
> > <assert test="contains( string(.),'@')">
> > error.email.wrongformat
> > </assert>
> ></rule>
> >
> >and have a translation like this in dictionary:
> ><message key="error.email.wrongformat">Wrong email format. Email should
look
> >like {0}.</message>
> >
> >then have this in the form:
> ><i18n:translate>
> > <i18n:text><xf:violation ref="/email"/></i18n:text>
> > <i18n:param>[EMAIL PROTECTED]</i18n:param>
> ></i18n:translate>
> >
> >The other problem here would be to know what are the needed params for a
> >particular case.
> </snip>
>
> Didn't get the part about "needed params". Haven't had time to study the
i18n
> stuff yet, but all this looks *very* cool.
>
> Cheers,
> --Michael
>
>
>
>
> "Konstantin
> Piroumian" To:
<[EMAIL PROTECTED]>
> <kpiroumian@apach cc:
> e.org> Subject: Re:
[Announcement] XMLForm 0.8.2 released
>
> 05/16/02 04:50 AM
> Please respond to
> cocoon-dev
>
>
>
>
>
>
> Hi!
>
> From: <[EMAIL PROTECTED]>
> >
>
> I'd like to comment on this:
>
> >
> > Do you plan to support Schematron <report> element? Would make it
easier
> to
> > write rules like "/foo is invalid if it contains any of the following
> > characters: #, &, *, %", or "/foo may contain only digits 0-9 and
decimal
> > point".
> >
> > Is there any way to implement Schematron <name> and <value-of> elements?
> Since
> > XMLForm validates against instance data rather than the entire form
> description,
> > I don't see how it can retrieve this sort of context. Still, it would
be
> nice
> > to be able to write rules like this:
> > <name ref="../xf:caption> cannot contain <value-of select
> > ="/some/xpath/expression">
> > to produce a violation like this:
> > "Street Name cannot contain a "$"
>
> If we make ai18n-enabled form then this approach can be a problem as we
> should have translations for all the possible cases and values. Haven't
yet
> time to investigate the possibilities better, but I think that one can use
> dictionary keys instead of a real message, e.g.:
>
> <rule context="/email">
> <assert test="contains( string(.),'@')">
> error.email.wrongformat
> </assert>
> </rule>
>
> and have a translation like this in dictionary:
> <message key="error.email.wrongformat">Wrong email format. Email should
look
> like {0}.</message>
>
> then have this in the form:
> <i18n:translate>
> <i18n:text><xf:violation ref="/email"/></i18n:text>
> <i18n:param>[EMAIL PROTECTED]</i18n:param>
> </i18n:translate>
>
> The other problem here would be to know what are the needed params for a
> particular case.
>
> Regards,
> Konstantin
>
> >
> > Cheers,
> > --Michael
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
