[eml-dev] Fwd: Issue on transforming from eml-2.0.1 to eml-2.1.0

[Margaret O'Brien]

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
========================