You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.fr> on 2012/12/02 10:21:27 UTC
New class: ObjectResolver, ObjectConverters
Hello all
Continuing the work on the XML side of things (ISO 19139), there is two
classes worth to note:
ObjectResolver [1]
---------------
ISO 19139 XML documents sometime contain an empty element with only a
"xlink:href", "idref" ou "uuidref" attribute. The full object definition
shall be fetched from the reference. When such attribute is found at
unmarshalling time, the proposed mechanism is to invoke the
corresponding "resolve" method from the ObjectResolver class. The user
can provide its own ObjectResolver instance as a Marshaller property.
The "idref" attributes are local to the current XML document and can be
partially handled by the standard @XmlID JAXB annotation. But "uuidref"
is a UUID to a document that may be defined anywhere. It could be a
primary key in a database internal to an agency. With the proposed
ObjectResolver class, user can override the resolve(MarshalContext,
UUID) method for returning the metadata object for the given UUID using
whatever method is appropriate for his application. I'm hesitant about
whether the default implementation should unconditionally returns null,
or use a UUID list of objects previously created in the currently
running JVM (using weak references).
ObjectConverters [2]
-----------------
By default, JAXB parses URL, URI, UUID etc. using the standard methods
(e.g. new URI(String)). However in practice, we are often facing badly
formatted metadata documents with invalid URL (a very common case is
users putting a file path in Windows syntax instead of URL).
ObjectConverters is a proposed hook for giving developers a chance to
catch those situations and handle the errors as appropriate for their
application. By default, the conversions are strict: invalid URL or URI
or UUID cause the parsing to fail. But users can override the methods
and, for example, replace some URL on-the-fly.
Comments are always welcome,
Martin
[1]
https://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/xml/ObjectResolver.html
[2]
https://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/xml/ObjectConverters.html
Re: New class: ObjectResolver, ObjectConverters
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
(About renaming ObjectResolver to ReferenceResolver)
Le 03/12/12 11:11, Joe White a écrit :
> +1 to the rename since we are actually resolving references, according to the initial email.
Done, thanks for the feedback. Also renamed "ObjectConverters" to
"ValueConverter" in a hope to emphases that we are converting mostly
attribute values, rather than changing a XML element type to another type.
Martin
Re: New class: ObjectResolver, ObjectConverters
Posted by Joe White <wh...@gmail.com>.
+1 to the rename since we are actually resolving references, according to the initial email.
Joe
On Dec 2, 2012, at 9:00 PM, Adam Estrada <es...@gmail.com> wrote:
> OK...I get it now. I think you're right in that ReferenceResolver would be better than Object. I fear that we will end up getting a ton of classes referred to as "Object" so the more descriptive the class name, the better.
>
> A
>
>
> On Dec 2, 2012, at 8:52 PM, Martin Desruisseaux wrote:
>
>> Hello Adam
>> Le 03/12/12 09:01, Adam Estrada a écrit :
>>> Excellent Martin...I like the ObjectResolver class and I think that the ObjectConverters class is always going to be sorely needed as we often think about metadata as a second class citizen.
>>
>> Thanks. But I'm still wondering if the class names are appropriate. I wonder if "ReferenceResolver" would be more appropriate than "ObjectResolver" since we resolve only idref, uuidref or href attributes, and if "ValueParser" would be more appropriate than "ObjectConverters" since this class is only about some attributes or elements values (URL, UUID, Locale) and do not convert, for example a metadata object to an other metadata object...
>>
>> Martin
>>
>
Re: New class: ObjectResolver, ObjectConverters
Posted by Adam Estrada <es...@gmail.com>.
OK...I get it now. I think you're right in that ReferenceResolver would be better than Object. I fear that we will end up getting a ton of classes referred to as "Object" so the more descriptive the class name, the better.
A
On Dec 2, 2012, at 8:52 PM, Martin Desruisseaux wrote:
> Hello Adam
> Le 03/12/12 09:01, Adam Estrada a écrit :
>> Excellent Martin...I like the ObjectResolver class and I think that the ObjectConverters class is always going to be sorely needed as we often think about metadata as a second class citizen.
>
> Thanks. But I'm still wondering if the class names are appropriate. I wonder if "ReferenceResolver" would be more appropriate than "ObjectResolver" since we resolve only idref, uuidref or href attributes, and if "ValueParser" would be more appropriate than "ObjectConverters" since this class is only about some attributes or elements values (URL, UUID, Locale) and do not convert, for example a metadata object to an other metadata object...
>
> Martin
>
Re: New class: ObjectResolver, ObjectConverters
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Adam
Le 03/12/12 09:01, Adam Estrada a écrit :
> Excellent Martin...I like the ObjectResolver class and I think that the ObjectConverters class is always going to be sorely needed as we often think about metadata as a second class citizen.
Thanks. But I'm still wondering if the class names are appropriate. I
wonder if "ReferenceResolver" would be more appropriate than
"ObjectResolver" since we resolve only idref, uuidref or href
attributes, and if "ValueParser" would be more appropriate than
"ObjectConverters" since this class is only about some attributes or
elements values (URL, UUID, Locale) and do not convert, for example a
metadata object to an other metadata object...
Martin
Re: New class: ObjectResolver, ObjectConverters
Posted by Adam Estrada <es...@gmail.com>.
Excellent Martin...I like the ObjectResolver class and I think that the ObjectConverters class is always going to be sorely needed as we often think about metadata as a second class citizen.
Adam
On Dec 2, 2012, at 4:21 AM, Martin Desruisseaux wrote:
> Hello all
>
> Continuing the work on the XML side of things (ISO 19139), there is two classes worth to note:
>
> ObjectResolver [1]
> ---------------
> ISO 19139 XML documents sometime contain an empty element with only a "xlink:href", "idref" ou "uuidref" attribute. The full object definition shall be fetched from the reference. When such attribute is found at unmarshalling time, the proposed mechanism is to invoke the corresponding "resolve" method from the ObjectResolver class. The user can provide its own ObjectResolver instance as a Marshaller property.
>
> The "idref" attributes are local to the current XML document and can be partially handled by the standard @XmlID JAXB annotation. But "uuidref" is a UUID to a document that may be defined anywhere. It could be a primary key in a database internal to an agency. With the proposed ObjectResolver class, user can override the resolve(MarshalContext, UUID) method for returning the metadata object for the given UUID using whatever method is appropriate for his application. I'm hesitant about whether the default implementation should unconditionally returns null, or use a UUID list of objects previously created in the currently running JVM (using weak references).
>
>
> ObjectConverters [2]
> -----------------
> By default, JAXB parses URL, URI, UUID etc. using the standard methods (e.g. new URI(String)). However in practice, we are often facing badly formatted metadata documents with invalid URL (a very common case is users putting a file path in Windows syntax instead of URL). ObjectConverters is a proposed hook for giving developers a chance to catch those situations and handle the errors as appropriate for their application. By default, the conversions are strict: invalid URL or URI or UUID cause the parsing to fail. But users can override the methods and, for example, replace some URL on-the-fly.
>
> Comments are always welcome,
>
> Martin
>
>
> [1] https://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/xml/ObjectResolver.html
> [2] https://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/xml/ObjectConverters.html
>
Re: New class: ObjectResolver, ObjectConverters
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Martin,
Thanks!
On 12/5/12 6:56 PM, "Martin Desruisseaux"
<ma...@geomatys.fr> wrote:
>Le 04/12/12 14:42, Mattmann, Chris A (388J) a écrit :
>> This sounds very cool. As our ISO 19139 support and 19115 support
>>evolve and get better, I'd be
>> very interested in providing a parser, and entry in the MIME type
>>database for Apache Tika by wrapping
>> the code you're adding to Apache SIS.
>
>That would be very nice! And I would be interested to known about pain
>points that Tika may encounter, so we would try to fix them.
>
>On a related issue, there is a new class committed recently. This is the
>proposed "central point" where developers can get convenience static
>methods for parsing/formatting XML. For now I didn't put the methods
>yet, only the key constants for properties to be given to JAXB
>[Un]Marshaller. In this proposal, those properties would be processed
>especially by the SIS custom marshaller (as a wrapper around the
>standard marshaller).
>
>https://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/xml/XML
>.html
Ahh that makes total sense.
Thanks!
Cheers,
Chris
>
> Martin
>
Re: New class: ObjectResolver, ObjectConverters
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Le 04/12/12 14:42, Mattmann, Chris A (388J) a écrit :
> This sounds very cool. As our ISO 19139 support and 19115 support evolve and get better, I'd be
> very interested in providing a parser, and entry in the MIME type database for Apache Tika by wrapping
> the code you're adding to Apache SIS.
That would be very nice! And I would be interested to known about pain
points that Tika may encounter, so we would try to fix them.
On a related issue, there is a new class committed recently. This is the
proposed "central point" where developers can get convenience static
methods for parsing/formatting XML. For now I didn't put the methods
yet, only the key constants for properties to be given to JAXB
[Un]Marshaller. In this proposal, those properties would be processed
especially by the SIS custom marshaller (as a wrapper around the
standard marshaller).
https://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/xml/XML.html
Martin
Re: New class: ObjectResolver, ObjectConverters
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Martin,
This sounds very cool. As our ISO 19139 support and 19115 support evolve and get better, I'd be
very interested in providing a parser, and entry in the MIME type database for Apache Tika by wrapping
the code you're adding to Apache SIS.
Thoughts?
http://tika.apache.org/
Cheers,
Chris
On Dec 2, 2012, at 1:21 AM, Martin Desruisseaux wrote:
> Hello all
>
> Continuing the work on the XML side of things (ISO 19139), there is two classes worth to note:
>
> ObjectResolver [1]
> ---------------
> ISO 19139 XML documents sometime contain an empty element with only a "xlink:href", "idref" ou "uuidref" attribute. The full object definition shall be fetched from the reference. When such attribute is found at unmarshalling time, the proposed mechanism is to invoke the corresponding "resolve" method from the ObjectResolver class. The user can provide its own ObjectResolver instance as a Marshaller property.
>
> The "idref" attributes are local to the current XML document and can be partially handled by the standard @XmlID JAXB annotation. But "uuidref" is a UUID to a document that may be defined anywhere. It could be a primary key in a database internal to an agency. With the proposed ObjectResolver class, user can override the resolve(MarshalContext, UUID) method for returning the metadata object for the given UUID using whatever method is appropriate for his application. I'm hesitant about whether the default implementation should unconditionally returns null, or use a UUID list of objects previously created in the currently running JVM (using weak references).
>
>
> ObjectConverters [2]
> -----------------
> By default, JAXB parses URL, URI, UUID etc. using the standard methods (e.g. new URI(String)). However in practice, we are often facing badly formatted metadata documents with invalid URL (a very common case is users putting a file path in Windows syntax instead of URL). ObjectConverters is a proposed hook for giving developers a chance to catch those situations and handle the errors as appropriate for their application. By default, the conversions are strict: invalid URL or URI or UUID cause the parsing to fail. But users can override the methods and, for example, replace some URL on-the-fly.
>
> Comments are always welcome,
>
> Martin
>
>
> [1] https://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/xml/ObjectResolver.html
> [2] https://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/xml/ObjectConverters.html
>