Bug #2162


eml versions and dateTimeDomain requirements

Added by Callie Bowdish over 18 years ago. Updated about 18 years ago.

morpho - general
Target version:
Start date:
Due date:
% Done:


Estimated time:


following error generated: cvc-complex-type.2.3: Element 'dateTimeDomain' must
have no character [children], because the types content type is element-only.

Conversation regarding the error having to do with two differing eml-versions
problem comes when someone adds a datatable to eml-2.0.0 - doesnt specify the
bounds and then opens the document in tree editor
<sid> and the tree editor enforces eml-2.0.0
<sid> and hence looks for the bound info
<sid> which is what happened in Callie's case
<sid> Mr. EML-2.0.1 agrees with you - whereas Mr. EML-2.0.0 doesnt
<vero> well since 2.0.1 is what we're using now...
<sid> Callie - add these to the list of things which will hopefully be fixed in
Morpho1.6.0 R C2

regarding the dateTimeDomain attribute and inside the bound tags you shud have
minimum and maximum

<sid> that error was probably that dateTimeDoamin cant be trimmed because it is
<vero> it's not required in the NDPW
<vero> is it?

Actions #1

Updated by Saurabh Garg over 18 years ago

this is a morpho bug... moving it under Morpho

Actions #2

Updated by Callie Bowdish over 18 years ago

Test sequence for dateTimeDomain error in Morpho 1.6.0 with documents created in
Morpho 1.5.0 that use eml 2.0.0

1. Created an EML file in old version of Morpho 1.5.1

<eml:eml packageId="bowdishOldMorpho.4.2" scope="system" system="knb"
xsi:schemaLocation="eml:// eml.xsd">
<dataset scope="document">

Used the data package wizard included the time setting.
<coverage scope="document">
<temporalCoverage scope="document">

2. Imported a table that used the MeasurementScale datetime choice and did not
include the dateTimeDomain

<attribute id="1130871221265" scope="document">
<attributeDefinition>Date of Record</attributeDefinition>
<dateTimeDomain> </dateTimeDomain>

3. Saved the data package in Morpho 1.5.1

4. Open the data package in Morpho 1.5.1 with no problems in the editor

5. Open the data package in Morpho 1.6.0 in the editor and get the following error

Unable to trim following nodes:



Please check if all the required values are entered and that there are no empty

The EML ID and References Parser at says that the document is valid

submitted by Callie Bowdish

Actions #3

Updated by Saurabh Garg over 18 years ago

Changing the QA contact for that bug.

Actions #4

Updated by Callie Bowdish about 18 years ago

<pmark> would you mind trying to nail down exactly what's wrong with dateTimeDomain?
<Callie> yes, we were just discussin it
<Callie> there is/were some legacy issues with the requirements for data time
boundries in 2.00
<pmark> I thought I fixed that
<pmark> on 1.6 release day I think someone found some strange behavior
<pmark> remember that?
<Callie> yes, I do
<will> Looking at the dates, I think that's what Comment #2 is talking about
--> In (~) has joined #kdi
<Callie> one component of the problem that is kind of tricky to nail down is
where creating or using documents used with Morpho 1.5.1 fits into the problem
<pmark> are we still supporting 1.5.1?
<Callie> that is not the plan
<Callie> everyone we contact is told to upgrade
<will> well, we should support the legacy documents already on the KNB
<pmark> and their old documents are automatically upgraded when opened in
morpho, ja?
<Callie> <eml:eml packageId="bowdishOldMorpho.4.2" scope="system" system="knb"
<Callie> xmlns:eml="eml://"
<Callie> xmlns:xsi=""
<Callie> xsi:schemaLocation="eml:// eml.xsd">
<Callie> <dataset scope="document">
<-- jhHome has quit (Quit: Client Exiting)
<Callie> seems to be part of the problem that I documented so if that code gets
<pmark> I'm working on bug 2221 which converts a 2.0.0 doc to 2.0.1 when they save
<pmark> but morpho 1.6 should still use 2.0.0 validation rules on 2.0.0 documents
<pmark> by "should" I mean, that's how it's programmed
<pmark> am I missing the point? :)
<Callie> right so after they save the document it changes to 2.0.1 but not before
<pmark> correct
<Callie> so if they open the editor they could run into problems
<pmark> (well, that's the plan and that's how it'll be soon)
<pmark> no, I don't think so
<pmark> unless you consider 2.0.0 validation a problem
<pmark> maybe the user should be prompted to convert to 2.0.1 when they open an
old doc?
<pmark> I think that makes more sense
<Callie> point 3. in my discription does mention saving the document before
getting the error, so I guess that would seem to fix the problem
<pmark> because if you edit a 2.0.0 doc with 2.0.0 validation rules, then save
and upgrade to 2.0.1 then it may not be valid, right? Or is 2.0.1 less strict
in every way?
<will> I think they made it so any valid 2.0.0 document is 2.0.1 valid
<pmark> ok then it's ok to upgrade at save time
<will> yeah
<Callie> I beleive so.
<will> it looks like the problem may have been that Morpho is trying to validate
with 2.0.0 schema
<will> which requires DateTimeDomain
<pmark> even 2.0.1 docs get validated as 2.0.0?
<will> I think the issue was that a 2.0.0 doc was getting converted to 2.0.1,
but still getting validated by 2.0.0
<pmark> have y'all heard any user complaints in this dep't?
<Callie> no, only me during testing
<will> not that I'm aware of
<Callie> let me check my emails.
<pmark> so there definitely is a distinguishable bug right now?
<will> the other alternative is that the bug resides in 1.5.1 which could be
letting people save invalid 2.0.0 docs
<pmark> Is it acceptable to take the easy route (for us) and tell users to
upgrade Morpho?
<-- Thomas has quit (Quit: Leaving)
<will> probably
<will> and to force upgrading to 2.0.1 hen the make changes to the documents
<will> *when they
<pmark> there's really no reason not to upgrade to 2.0.1 from 2.0.0
<will> true
<pmark> but currently it's implemented as an option at save time
<Callie> Also I think that when documents are saved and the
xsi:schemaLocation="eml:// automatically gets
updated that the problem will no longer be there
<pmark> great
<will> yeah, I think forcing the document upgrade will resolve the issue

Actions #5

Updated by Redmine Admin almost 11 years ago

Original Bugzilla ID was 2162


Also available in: Atom PDF