oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <chris.a.mattm...@jpl.nasa.gov>
Subject Re: Changes to Elements.xml file
Date Tue, 24 May 2011 07:57:23 GMT
Hi Michael,

Thanks for your email!

You can find the OODT Apache archives here:

http://mail-archives.apache.org/mod_mbox/oodt-dev/

As for standards, best practices are certainly part of them but we do have a few standards
that we try and stick to including Dublin Core, ISO-11179, RDF, etc., when we are defining
metadata elements. For your purposes in elements.xml in CAS, the biggest approach is to use
unique, namespaced identifiers for element IDs, product type IDs, etc.

HTH!

Cheers,
Chris

On May 23, 2011, at 1:14 PM, Starch, Michael D (388L) wrote:

> Chris,
> 
> Is there some sort of coding standards document that I should be abiding by, or does
oodt just follow standard java "best practices"?  This is the kind of information that seems
like it would be easier for me to look up rather than ask on the developer list.  
> 
> Finally, how can I access the archived dev-list mailings?
> 
> Thanks,
> 
> Michael
> 
> 
> On May 19, 2011, at 11:06 PM, Mattmann, Chris A (388J) wrote:
> 
>> Hi Michael,
>> 
>> I'd be happy to reply below, but yes I'd suggest initially CC'ing dev@oodt.apache.org.
Giving this information is great, but I prefer the community to benefit from these types of
discussions (and it means that I or you or Albert or Cecilia can point others to this question
if it is asked again rather than typing the same answer again or fwd'ing something private).
Also no worries about researching it -- you can ask questions on that list -- researched or
not. We welcome feedback from the community. 
>> 
>> Answers inline below:
>> 
>> On May 19, 2011, at 2:44 PM, Starch, Michael D (388L) wrote:
>> 
>>> Chris,
>>> 
>>> In order to create tables in the new database architecture that Brian Foster
set up for use, we need the ability to specify some information beyond that which is stored
in elements.xml.  We wish to store this information as part of PCS, rather than continually
haggling back and forth with our DBA in order to get this set in an ad-hoc manner.
>>> 
>>> The data we need to store is:
>>> 
>>> -Is it a vector type?
>>> -Data-type
>>> -Max data size
>>> and potentially a few more items.
>> 
>> Gotcha.
>> 
>>> 
>>> As it stands now, Brian has used the DCElement tag in elements.xml file in order
to store some of this information but not all of it.  Thus it seems natural that the rest
of this information gets stored along side it.
>>> 
>>> There seem to be three ways to accomplish this:
>>> 
>>> 1. Add more information to the DCElement tag, 
>>> 2. Add additional tags to the element file containing this information
>>> 3. Create a sperate file to store this information (Not part of PCS)
>> 
>> I've got a 4th option.
>> 
>> 4. Write a new ValidationLayer implementation, that extends XMLValidationLayer, but
adds your desired information to elements.xml. For that extra information, I'd favor your
proposed option #2 -- I think it's cleaner.
>> 
>>> 
>>> As head of oodt, we were looking for you input as to which option to choose,
or if you wish this question to be brought to dev@oodt.apache, where can I research this information
before asking the question on that list?
>>> 
>>> Below is a brief analysis of each option, from our perspective.
>>> 
>>> Thanks,
>>> 
>>> Michael Starch
>>> 
>>> 1. Add more information to the DCElements tag.
>>> 	-I believe Brain said this tag was unused, so he "borrowed" it to suit this
purpose.
>>> 	-Adding more information to the tag would "hijack" this tag to a further extent.
>>> 	-The changes could be made locally to our ColumnBasedDataSourceCatalog in the
manner Brian already used.
>>> 	-If the DCElement is used ouside of the new use Brian invented, this change
could affect the intended (original) use
>> 
>> I don't like this one (nor do I think others will) since it hijacks dcElement (which
is supposed to be a mapping to a Dublin Core element name, rather than used for other information).
>> 
>>> 
>>> 2. Add more tags to elements.xml
>>> 	-Most elegant solution, as each data field has a tag specified to hold exactly
it
>>> 	-No need to use tags which were originally intended for some other purpose
>>> 	-It is an architectural change, changing the format of the elements.xml file
>>> 	-Must be done carefully to prevent us from deviating from apache-oodt when it
is not necessary to do so.
>> 
>> +1 for this option.
>> 
>>> 	
>>> 3. A separate file
>>> 	-Creates data/configuration duplication, as some of these fields must stay (in
some form) in elements.xml
>>> 	-Separates similar pieces of data
>>> 	-Doesn't alter PCS as it exists now
>> 
>> This is fine too, but I prefer #2.
>> 
>>> 
>>> We favor number 1 or number 2 as it keeps similar data together, and feels like
it is the most logical place to store this information.
>>> 
>>> I personally favor number 2, as it does not use tags for unintended purposes,
but I do not wish to make a change that affects our compatibility with apache code.  Hence
your input.
>>> 
>> 
>> +1 to your preference. I think the way to accomplish it is to write a YourExtendedValidationLayer
extends XMLValidationLayer and that provides a customized:
>> 1. YourElementClass extends Element 
>>    - provides extra props (getters+setters) that you want to leverage
>> 2. implementations of the SerDe for your specialized elements.xml that includes those
extra tags
>> 3. provides the ability to access this ValidationLayer information and Element information
in ColumnBasedDataSourceCatalog.
>> 
>> BTW, I think it would be great to bake up patches for Apache OODT for what you are
working on, including ColumnBasedDataSourceCatalog (already there but in a branch, would be
nice to forward port to trunk, and your proposed ValidationLayer and Element extensions).
Thoughts? Do you have the time? I think the community at Apache would sincerely appreciate
the effort.
>> 
>> Cheers,
>> Chris
>> 
>> P.S. Would you be OK with me forwarding this thread to dev@oodt.a.o? I think there's
some good info here that I'd hate to be lost in the ether...
>> 
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Chris Mattmann, Ph.D.
>> Senior Computer Scientist
>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> Office: 171-266B, Mailstop: 171-246
>> Email: chris.a.mattmann@nasa.gov
>> WWW:   http://sunset.usc.edu/~mattmann/
>> Phone: +1 (818) 354-8810
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Adjunct Assistant Professor, Computer Science Department
>> University of Southern California, Los Angeles, CA 90089 USA
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 
> 


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Mime
View raw message