Use of Option in generated case classes

[OlegYch]

Hi.

First, thanks for your amazing work.
I'm using scalaxb 0.6.5 to generate code for a webservice.
Currently for this input:

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:ns1="http://schemas.datacontract.org/2004/07/
Entities"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://tempuri.org/">
<wsdl:types>
<xsd:schema
attributeFormDefault="unqualified"
elementFormDefault="qualified"
targetNamespace="http://schemas.datacontract.org/2004/07/
Entities">
<xsd:complexType name="BaseProperty">
<xsd:sequence>
<xsd:element minOccurs="0" name="Definition" nillable="true"
type="ns1:PropertyDefinition"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="BaseProperty" nillable="true"
type="ns1:BaseProperty"/>
<xsd:complexType name="PropertyDefinition">
<xsd:sequence>
<xsd:element name="test" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="PropertyDefinition" nillable="true"
type="ns1:PropertyDefinition"/>
</xsd:schema>
</wsdl:types>
</wsdl:definitions>

the following output is generated:

case class BaseProperty(Definition:
Option[Option[PropertyDefinition]])
case class PropertyDefinition(test: String)

This use of nested options seems to be redundant, is there a way to
avoid it?
In addition i think it would be nice if generated classes where using
default argument, so ideally it would look like
case class BaseProperty(Definition: Option[PropertyDefinition] = None)

Is this possible?

Thanks, Oleg.

[eugene yokota]

Hi Oleg,

Thanks for your interest in scalaxb!

> case class BaseProperty(Definition:
> Option[Option[PropertyDefinition]])
> case class PropertyDefinition(test: String)
>
> This use of nested options seems to be redundant, is there a way to
> avoid it?

No, blame the schema for redundancy. There are some situations where
one needs to clearly distinguish the difference between nill value and
lack of an element, so double Option is necessary from my point of
view.
For example, as a mandate of data binding tool scalaxb needs to
support round trips:
Start out with an XML document -> turn it into case class -> turn it
back into the original document.

Suppose we now encode nillable and optional (minOccurs = 0) element as
plain Option[PropertyDefinition]. You parse a document that has nil
value, it turns into None.
Now, when someone calls toXML to turn it back into XML document, how
would I know if it was nil or simply missing?

> In addition i think it would be nice if generated classes where using
> default argument, so ideally it would look like
> case class BaseProperty(Definition: Option[PropertyDefinition] = None)
>
> Is this possible?

I would have to think about this one.
For attributes, I think None are already supplied as default argument,
but I am not sure if it would make sense for elements as well.

-eugene

[eugene yokota]

Ok. Could you open github issues separately for those two cases?
Any case that modifies the original intent of the schemas have lower
priority compared to bugs, but I'll keep them as christmas gift ideas.

-eugene

On Mon, Nov 7, 2011 at 4:21 PM, OlegYch <oleg...@gmail.com> wrote:
> Hi Eugene.
>
> Thanks for the explanation. I'm really surprised how thoroughly you
> handle such subtleties.
>
> The thing is, that wsdl piece is generated by .NET server and I really
> doubt it can be corrected or if the underlying serializer
> differentiates between nil value and no element. E.g. the code
> generated by Axis2 for same piece just outputs nil value and doesn't
> care if it's nil or no element when parsing. I would suggest to add an
> option to flatten options in generate code, otherwise pattern matching
> can become cumbersome.
>
> As for default arguments for optional elements I don't see any
> correctness implications, would be great if you could share you
> thoughts on this.
>
> Thanks, Oleg.

[OlegYch]

Hi Eugene.

Thanks for the explanation. I'm really surprised how thoroughly you
handle such subtleties.

The thing is, that wsdl piece is generated by .NET server and I really
doubt it can be corrected or if the underlying serializer
differentiates between nil value and no element. E.g. the code
generated by Axis2 for same piece just outputs nil value and doesn't
care if it's nil or no element when parsing. I would suggest to add an
option to flatten options in generate code, otherwise pattern matching
can become cumbersome.

As for default arguments for optional elements I don't see any
correctness implications, would be great if you could share you
thoughts on this.

Thanks, Oleg.

On Nov 5, 3:50 am, eugene yokota <eed3s...@gmail.com> wrote:

[OlegYch]

Hi Eugene.

Thanks for the explanation. I'm really surprised how thoroughly you
handle such subtleties.

The thing is, that wsdl piece is generated by .NET server and I really
doubt it can be corrected or if the underlying serializer
differentiates between nil value and no element. E.g. the code
generated by Axis2 for same piece just outputs nil value and doesn't
care if it's nil or no element when parsing. I would suggest to add an
option to flatten options in generate code, otherwise pattern matching
can become cumbersome.

As for default arguments for optional elements I don't see any
correctness implications, would be great if you could share you
thoughts on this.

Thanks, Oleg.

On Nov 5, 3:50 am, eugene yokota <eed3s...@gmail.com> wrote:

[OlegYch]

Cool, thanks.

Here they are:
https://github.com/eed3si9n/scalaxb/issues/112
https://github.com/eed3si9n/scalaxb/issues/113