Return-Path: 
 <cocoon-dev-return-26928-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 20563 invoked by uid 500); 17 May 2002 13:19:09 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 20550 invoked from network); 17 May 2002 13:19:09 -0000
Message-ID: <031201c1fda5$504c66a0$12c68842@galina>
From: "Ivelin Ivanov" <ivelin@apache.org>
To: <cocoon-dev@xml.apache.org>
References: <OF2216067B.6B47FFFC-ON88256BBB.002DA851@collegenet.com>
 <006f01c1fccf$edfc76a0$6150000a@flagship.ru>
Subject: Re: [Announcement] XMLForm 0.8.2 released
Date: Fri, 17 May 2002 08:18:19 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N


Thanks for the comments, Konstantin.

Seems like the plan to add a few i18n tags directly in the XMLForm wizard
example will pay off.




----- Original Message -----
From: "Konstantin Piroumian" <kpiroumian@apache.org>
To: <cocoon-dev@xml.apache.org>
Sent: Thursday, May 16, 2002 6:50 AM
Subject: Re: [Announcement] XMLForm 0.8.2 released


> Hi!
>
> From: <mratliff@collegenet.com>
> >
>
> 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>user@hostname.com</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: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


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