Ron,
apologies, I was applying a mistaken assumption, I have written a test
program and verified that neither the createDateTimeFromString of
ModelFactoryImpl nor of XMLTypeFactoryImpl are invoked during XML
deserialization of an element of type =xsd:dateType. So now your previous
note makes perfect sense.
Regards, Kelvin.
On 24/01/07, Ron Gavlin <[EMAIL PROTECTED]> wrote:
>
> 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]
>
>
