[eml-dev] [morpho-dev] Fwd: Issue on transforming from eml-2.0.1 to eml-2.1.0
Jing Tao
tao at nceas.ucsb.edu
Mon Dec 15 10:09:20 PST 2008
When morpho describe offline data which data location is not available,
morpho 1.6.1 put a space as objectname, 1.6.2 release candidate change to
put "Unavailable" as objectname. Is this okay? In this case, morpho
doesn't have interface for user to input object name.
Thanks,
Jing
Jing Tao
National Center for Ecological
Analysis and Synthesis (NCEAS)
735 State St. Suite 204
Santa Barbara, CA 93101
On Mon, 15 Dec 2008, Margaret O'Brien wrote:
> Morpho should just ask for an objectName, then, even if the table is not
> included. One way to use this feature (along with the "save duplicate") is
> for creating/editing a template.
>
> However, I noticed something else (Morpho 1.6.1):
> you can describe and save a package with an empty table, ie, the template --
> no problem.
> but when you to to edit it (or a saved duplicate), clicking the OK button
> results in:
> "Unable to trim following nodes:
> eml/dataset/(CHOICE)/dataTable(SEQUENCE)/physical/(SEQUENCE)/objectName"
>
> when all it has is the ' '. So Morpho already cannot handle the empty-string
> content.
>
> margaret
>
>
> Matt Jones wrote:
>> Hi Margaret,
>>
>> I think Morpho should be able to fill in the objectName even if they
>> don't upload the file -- the name still exists. I agree that the
>> delimiter fields should allow whitespace characters because whitespace
>> is legitimate as delimiters, but it seems like Morpho should be able
>> to deal with providing the objectName even if it is required and
>> doesn't allow just whitespace. I must be missing a critical issue
>> here, because this doesn't seem like a problem to me.
>>
>> Matt
>>
>> On Mon, Dec 15, 2008 at 7:30 AM, Margaret O'Brien <mob at icess.ucsb.edu>
>> wrote:
>>
>>> The problem is a Morpho feature that allows an author to completely
>>> describe
>>> a dataTable without actually attaching it, and objectName is a required
>>> child of dataTable. To accommodate this, Morpho has been putting a single
>>> space into the objectName field to meet the "content" requirement of
>>> xs:string. So it seems that there are these choices: come up with an
>>> acceptable string for Morpho to use in these cases and leave the schema
>>> alone, define another type so Morpho can have some other acceptable
>>> content,
>>> make objectName optional, or remove this feature from Morpho.
>>>
>>> As far as strings like ' ' , and '\t' -- these have always been
>>> legitimate
>>> fieldDelimeters. '\t' is allowed by the pattern currently in the
>>> NonEmptyStringType. But since ' ' was not, I reset the types for
>>> *Delimeters
>>> back to xs:string. We could define a separate pattern for delimeters and
>>> create very specific examples
>>>
>>>
>>> Matt Jones wrote:
>>>
>>>> Discussion merited sometime soon?
>>>>
>>>> Matt
>>>>
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Matt Jones <jones at nceas.ucsb.edu>
>>>> Date: Fri, Dec 12, 2008 at 9:14 PM
>>>> Subject: Re: [eml-dev] Issue on transforming from eml-2.0.1 to eml-2.1.0
>>>> To: Jing Tao <tao at nceas.ucsb.edu>
>>>>
>>>>
>>>> The whole point of changing the schema was to prevent people from
>>>> leaving required elements with empty content. Changing it to
>>>> 'Unavailable' is equally unappealing. If we will accept 'Unavailable'
>>>> as a schema choice, we might as well just go ahead and make all
>>>> elements in EML optional so that people don't have to put in some
>>>> garbage text just to get it to validate. But if we agree that there
>>>> are minimum requirements for things to make sense, then we also
>>>> shouldn't accept '', ' ', '\t', 'N/A', 'Unavailable' or any other
>>>> non-content placeholder. Unfortunately, we can't stop people from
>>>> doing this through purely technical means, but at least its clear to
>>>> them that its not appropriate with the new content model.
>>>>
>>>> The downside, of course, is that it prevents automatic and full
>>>> translation from eml 2.0.1 to eml 2.1, but we knew they were not
>>>> backwards compatible, so this won't be the only case.
>>>>
>>>> Matt
>>>>
>>>> On Fri, Dec 12, 2008 at 8:26 PM, Jing Tao <tao at nceas.ucsb.edu> wrote:
>>>>
>>>>
>>>>> Hi, Margaret:
>>>>>
>>>>> I am writting a java program to transform eml201(eml200) documents to
>>>>> eml210
>>>>> in a Metacat by the style sheet from eml module. It works now in my test
>>>>> server. But I found a issue here:
>>>>>
>>>>> In some eml201 documents, some elements, e.g. objectName, have a space
>>>>> as
>>>>> text value. It is valid in eml201. After transforming to eml210
>>>>> document,
>>>>> the space value will be kept there. However, current eml-210 schema
>>>>> doesn't
>>>>> allow the value to be a space. This results that the generated eml210
>>>>> document is invalid.
>>>>>
>>>>> I guess there are maybe two possible solutions:
>>>>>
>>>>> First, change the eml schema - back to string type rather than non-empty
>>>>> string type in those elements.
>>>>>
>>>>> Second, in the eml201to210.xsl style sheet, if it finds the text value
>>>>> of
>>>>> a
>>>>> leaf node is a space, replace the space by some other text - such as
>>>>> "Unavailable".
>>>>>
>>>>> Do you have any suggestion on this?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jing
>>>>>
>>>>> Jing Tao
>>>>> National Center for Ecological
>>>>> Analysis and Synthesis (NCEAS)
>>>>> 735 State St. Suite 204
>>>>> Santa Barbara, CA 93101
>>>>> _______________________________________________
>>>>> Eml-dev mailing list
>>>>> Eml-dev at ecoinformatics.org
>>>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> Matthew B. Jones
>>>> Director of Informatics Research and Development
>>>> National Center for Ecological Analysis and Synthesis (NCEAS)
>>>> UC Santa Barbara
>>>> jones at nceas.ucsb.edu Ph: 1-907-523-1960
>>>> http://www.nceas.ucsb.edu/ecoinfo
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>
>>>>
>>>>
>>>>
>>>>
>>> --
>>>
>>>
>>> ========================
>>> Margaret O'Brien
>>> Information Management
>>> Santa Barbara Coastal LTER Marine Science Institute
>>> University of California
>>> Santa Barbara, CA 93106-6150
>>>
>>> 805-893-2071
>>> mob at icess.ucsb.edu
>>> http://sbc.lternet.edu
>>> ========================
>>>
>>>
>>>
>>
>>
>>
>>
>
> --
>
>
> ========================
> Margaret O'Brien
> Information Management
> Santa Barbara Coastal LTER Marine Science Institute
> University of California
> Santa Barbara, CA 93106-6150
>
> 805-893-2071
> mob at icess.ucsb.edu
> http://sbc.lternet.edu
> ========================
>
> _______________________________________________
> Morpho-dev mailing list
> Morpho-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/morpho-dev
>
>
More information about the Eml-dev
mailing list