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.1 feature: > >> 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]
