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

[Margaret O'Brien]

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