Hi Kelvin,
Is XMLFactoryImpl.createDateTimeFromString() invoked during
de-serialization or is it invoked by DataHelper.toDateTime()? I assumed
the latter but based on your feedback it appears that isn't the case. Please
clarify.
Also, the DataHelperImpl.to Date/Calendar/DateTime implementations are
broken. I opened a JIRA for these. Assuming XMLFactoryImpl is not the place
to perform this validation, would DataHelperImpl be a better location?
Furthermore, would it be appropriate to leverage EMF's XMLCalendar to fix
DataHelperImpl's Date problems or is it off limits to use EMF internal
classes like XMLCalendar?
Thanks,
- Ron
----- Original Message ----
From: kelvin goodson <[EMAIL PROTECTED]>
To: [email protected]
Sent: Wednesday, January 24, 2007 6:00:57 AM
Subject: Re: Problem w/SDO xsd:dateTime value being validated using EMF
Diagnostician.validate()
Hi Ron,
thanks for offering to make a contribution, however, I'm
confused. Your
last note seems to suggest that the consensus of the discussion in this
thread is that we might begin adding validation to deserialization code
over
and above that which is present and unavoidable in the conversion from XML
to the instance class. However the way I have read the discussion is
that
for performance reasons it would be preferable to leave the level of
validation at deserialization to to that which is unavoidable and to make
available further validation on request.
Regards, Kelvin.
On 23/01/07, Ron Gavlin <[EMAIL PROTECTED]> wrote:
>
> Hi Frank,
>
> That makes sense. Thanks for clarifying the issue for me. I'll go ahead
> and open an JIRA enhancement request for validation code to be added to
> XMLFactoryImpl.createDateTimeFromString(). Would you accept a
contribution
> that implements the validation using EMF's XMLCalendar?
>
> - Ron
>
> ----- Original Message ----
> From: Frank Budinsky <[EMAIL PROTECTED]>
> To: [email protected]
> Sent: Monday, January 22, 2007 1:40:19 PM
> Subject: Re: Problem w/SDO xsd:dateTime value being validated using EMF
> Diagnostician.validate()
>
>
> This is a touchy issue because of performance. People care a lot about
the
> load time for loading XML documents. If we assume that the XML is valid
> (which it should be if it was when it was serialized) there is no need
to
> slow down the loader with validation overhead.
>
> EMF does not check that nonNegativeInteger valures are not negative. The
> only "default" validation you get is the validation provided by the
> instanceClass that the xsd type maps to. For nonNegativeInteger that is
> BigInteger - so it does check that it's a number, but doesn't check for
> the negative part.
>
> The difference between SDO 1 and 2 is that the instance class for the
> various date types has changed to String, so some of the instanceClass
> validation that we got for free with SDO 1 (EMF) is no longer there in
SDO
> 2.
>
> Frank.
>
>
> Ron Gavlin <[EMAIL PROTECTED]> wrote on 01/22/2007 01:13:21 PM:
>
> > I apologize for the confusion. Let me try to be more clear.
> >
> > I think there should be a minimal level of validation just to ensure
> > that all primary XML data types (see http://www.w3.org/TR/2003/WD-
> > xpath-functions-20030502/#datatypes) (including dateTime, duration,
> > unsignedInt, nonNegativeInteger, etc.) are valid. Am I correct that
> > this is approx. what EMF de-serialization provides by default? When
> > SDO de-serializes a nonNegativeInteger, does it "validate" to make
> > sure the value is an integer is that it is non-negative? If so (and
> > I think it should if it doesn't currently), then I think it would be
> > consistent to handle xsd:date-related types likewise. The lack of
> > classes XMLGregorianCalendar and Duration in JDK 1.4 is likely the
> > source of most of this confusion. Furthermore, I suspect SDO de-
> > serializes dates, dateTimes, and durations to Strings because JDK 1.
> > 4 is missing these javax.xml... classes. Since the xsd:date-related
> > types are primary XML data types, I think it makes most sense to
> > validate all of them on de-serialization even if SDO stores them
> > internally as a Strings. What do you think?
> >
> > - Ron
> >
> > ----- Original Message ----
> > From: Frank Budinsky <[EMAIL PROTECTED]>
> > To: [email protected]
> > Sent: Monday, January 22, 2007 9:59:05 AM
> > Subject: Re: Problem w/SDO xsd:dateTime value being validated using
> > EMF Diagnostician.validate()
> >
> >
> > Ron, you seem to be contradicting yourself. First you said it should
not
>
> > validate:
> >
> > > I would think it makes sense for the SDO
> > > deserializer to behave like a non-validating XML parser.
> >
> > and then you said it should:
> >
> > > should the SDO 2 Deserializer validate an xsd:dateTime like the
> > > EMF-based SDO 1 did? I think yes.
> >
> > Anyway, I think I agree with Yang. For performance reasons, we
probably
> > should not validate during deserialization, and leave it to an
explicit
> > validation request.
> >
> > Frank.
> >
> > Ron Gavlin <[EMAIL PROTECTED]> wrote on 01/21/2007 05:34:52 PM:
> >
> > > So, should the SDO 2 Deserializer validate an xsd:dateTime like the
> > > EMF-based SDO 1 did? I think yes. Do you agree?
> > >
> > > - Ron
> > >
> > > Yang ZHONG wrote:
> > > > Agree with Ron:
> > > > 1. Deserializer (and setters) don't want to validate since not
each
> > > > user is
> > > > fine with the performance drawback
> > > > 2. provide standalone validation
> > > >
> > > >
> > > > On 1/19/07, Ron Gavlin <[EMAIL PROTECTED]> wrote:
> > > >>
> > > >> Hi Frank,
> > > >>
> > > >> Thanks for getting back to me. I would think it makes sense for
the
>
> > SDO
> > > >> deserializer to behave like a non-validating XML parser. Then SDO
> > > >> validation
> > > >> would behave much like an XML validator. What do you think?
> > > >>
> > > >> - Ron
> > > >>
> > > >> ----- Original Message ----
> > > >> From: Frank Budinsky <[EMAIL PROTECTED]>
> > > >> To: [email protected]
> > > >> Sent: Friday, January 19, 2007 2:29:34 PM
> > > >> Subject: Re: Problem w/SDO xsd:dateTime value being validated
using
>
> > EMF
> > > >> Diagnostician.validate()
> > > >>
> > > >>
> > > >> Hi Ron,
> > > >>
> > > >> You're right about the difference between SDO 1 and 2. The
> > instanceClass
> > > >> for SDO 1 xsd:dateTime was XMLCalendar, which enforces valid
values
>
> > when
> > > >> setting (deserializing). Since SDO 2 uses String for the
> > instanceClass,
> > > >> there's no automatic enforcement. The SDO spec doesn't really say
> > > >> anything
> > > >> about whether an implementation should do immediate validation on
> > things
> > > >> like this, or if it should be deferred until a validator is run.
> > > >>
> > > >> This question, and the more general issue of validation, is one
of
> > the
> > > >> items that is planned for SDO 3.
> > > >>
> > > >> As far as Tuscany is concerned, we could do validation in this
case
>
> > by
> > > >> adding validation code in the method
> > > >> XMLFactoryImpl.createDataTimeFromString(), assuming that is
> > consistent
> > > >> with the SDO 3 direction. For complete (deferred) validation,
> Tuscany
> >
> > > >> can
> > > >> either implement it using EMF (as you suggest) or we may be able
to
>
> > > >> write
> > > >> a pure SDO validator, once we make facet constraints available
with
>
> > SDO
> > > >> APIs - i.e., as soon as we finish implementing the new 2.1feature:
> > > >> getInstanceProperties() and get(Property) on Type and Property.
The
>
> > > >> later
> > > >> approach is more work, but consistent with our goal of trying not
> to
> > > >> rely
> > > >> on EMF being used in the implementation of SDO.
> > > >>
> > > >> Frank.
> > > >>
> > > >>
> > > >> Ron Gavlin <[EMAIL PROTECTED]> wrote on 01/19/2007 09:39:40 AM:
> > > >>
> > > >> > Hi Kelvin/Frank,
> > > >> >
> > > >> > Do either of you have any thoughts or insights re: the
questions
> I
> > > >> > raised in my prior note?
> > > >> >
> > > >> > Thanks in advance for your assistance,
> > > >> >
> > > >> > - Ron
> > > >> >
> > > >> > ----- Original Message ----
> > > >> > From: Ron Gavlin <[EMAIL PROTECTED]>
> > > >> > To: [email protected]
> > > >> > Sent: Wednesday, January 17, 2007 9:38:08 AM
> > > >> > Subject: Re: Problem w/SDO xsd:dateTime value being validated
> using
> > > >> > EMF Diagnostician.validate()
> > > >> >
> > > >> >
> > > >> > Thanks for the reply, Frank.
> > > >> >
> > > >> > I believe in EMF SDO 1, loading a DataGraph with an invalid
xsd:
> > > >> > dateTime value behaved much like loading a DataGraph with an
> > invalid
> > > >> > xsd:integer. Here, xsd:dateTime fields were parsed into EMF
> > > >> > XMLCalendar instances and therefore parsing errors were
reported
> at
> > > >> > load time. Tuscany SDO does not behave this way. Does the fact
> that
> > > >> > the SDO spec states that xsd:dateTime gets rendered as a String
> > > >> > imply that parsing should not be performed at load time and
> > > >> > therefore invalid xsd:dateTime values ignored?
> > > >> >
> > > >> > Does the SDO spec plan to address validation in a later
revision?
>
> > If
> > > >> > Tuscany SDO were to support validation, do you think Tuscany
> would
> > > >> > roll its own validation, use the validation capabilities
built-in
>
> > to
> > > >> > EMF, or use the EMFT Validation Framework? Would it be
> appropriate
> > > >> > for me to create a JIRA to document this enhancement request?
> > > >> >
> > > >> > I was thinking of writing a ModelValidator that is responsible
> for
> > > >> > validating the types defined in ModelPackageImpl. It would
> delegate
> > > >> > to EMF's DynamicEDataValidator for some types and implement
> custom
> > > >> > validation for others like DateTime. In order to implement this
> > > >> > capability, I would register the ModelPackageImpl and
> > ModelValidator
> > > >> > with the EMF EValidatorRegistry. Does this seem like a
reasonable
> > > >> > approach? Where do you think it would make most sense to
perform
> > > >> > this registration?
> > > >> >
> > > >> > - Ron
> > > >> >
> > > >> > ----- Original Message ----
> > > >> > From: Frank Budinsky <[EMAIL PROTECTED]>
> > > >> > To: [email protected]
> > > >> > Sent: Tuesday, January 16, 2007 3:24:59 PM
> > > >> > Subject: Re: Problem w/SDO xsd:dateTime value being validated
> using
> > > >> > EMF Diagnostician.validate()
> > > >> >
> > > >> >
> > > >> > I don't know if it worked in SDO 1 either, but a big change in
> this
> >
> > > >> area
> > > >>
> > > >> > is that the xsd types now map to commonj.sdo types as descirbed
> in
> > the
> > > >> SDO
> > > >> > 2 spec. In SDO 1, they mapped to types in the EMF
XMLTypePackage.
> > > >> >
> > > >> > In SDO 2 (Tuscany), xsd:dateTime maps to this type (defined in
> > > >> > sdoModel.xsd):
> > > >> >
> > > >> > <xsd:simpleType name="DateTime"
> > > >> sdoJava:instanceClass="java.lang.String">
> > > >> > <xsd:restriction base="xsd:dateTime"/>
> > > >> > </xsd:simpleType>
> > > >> >
> > > >> > It, along with all of the commonj types, is generated in class
> > > >> > org.apache.tuscany.sdo.model.impl.ModelFactoryImpl. I don't
know
> > > >> how the
> > > >>
> > > >> > EMF validator will handle this type.
> > > >> >
> > > >> > Frank.
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > Ron Gavlin <[EMAIL PROTECTED]>
> > > >> > 01/16/2007 01:05 PM
> > > >> > Please respond to
> > > >> > [email protected]
> > > >> >
> > > >> >
> > > >> > To
> > > >> > tuscany-user tuscany-user <[email protected]>
> > > >> > cc
> > > >> >
> > > >> > Subject
> > > >> > Problem w/SDO xsd:dateTime value being validated using EMF
> > > >> > Diagnostician.validate()
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > Greetings,
> > > >> >
> > > >> > I have an xsd:dateTime child element in an XML Schema that I
use
> to
> > > >> > statically generate Tuscany SDO classes. Since Tuscany does not
> > > >> currently
> > > >> > provide a schema validation API, I have been using EMF to
> > accomplish
> > > >> this
> > > >> > task using the following code:
> > > >> >
> > > >> > ...
> > > >> > Diagnostic diagnostic =
> > > >> > Diagnostician.INSTANCE.validate((EObject)
> > > >> > myDataObjectwithDateTimeChildProperty);
> > > >> > if (diagnostic.getSeverity() == Diagnostic.ERROR)
> > > >> > {
> > > >> > throw new Exception(diagnostic.getChildren().toString());
> > > >> > }
> > > >> >
> > > >> > This technique works fine for most schema validation issues,
like
> > > >> min/max
> > > >> > facet length enforcement for child xsd:strings, etc. However,
EMF
>
> > is
> > > >> > performing no validation against my Tuscany DateTime field (I
can
>
> > > >> supply
> > > >> a
> > > >> > bogus dateTime and no diagnostic error is generated). Is this
an
> > EMF
> > > >> > problem or a Tuscany/EMF integration problem? I thought this
used
>
> > to
> > > >> work
> > > >> > with the Eclipse EMF-based SDO 1.0 implementation but I may be
> > wrong.
> > > >> Any
> > > >> > suggestions would be greatly appreciated.
> > > >> >
> > > >> > Thanks in advance,
> > > >> >
> > > >> > - Ron
> > > >> >
> > > >> >
> > ---------------------------------------------------------------------
> > > >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > >> > For additional commands, e-mail:
[EMAIL PROTECTED]
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > ---------------------------------------------------------------------
> > > >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > >> > For additional commands, e-mail:
[EMAIL PROTECTED]
> > > >> >
> > > >> >
> > ---------------------------------------------------------------------
> > > >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > >> > For additional commands, e-mail:
[EMAIL PROTECTED]
> > > >> >
> > > >> >
> > ---------------------------------------------------------------------
> > > >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > >> > For additional commands, e-mail:
[EMAIL PROTECTED]
> > > >> >
> > > >>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > >> For additional commands, e-mail: [EMAIL PROTECTED]
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > >> For additional commands, e-mail: [EMAIL PROTECTED]
> > > >>
> > > >>
> > > >
> > > >
> > >
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
