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]
