FacetEnumartionImpl.getValue(AtomBridge<A>) method always returns null

[GoogleCodeExporter]

(from email discussion with Amy Lewis)
Looking through it quickly, what we need to do is to pass the type from the 
XMLEnumeration into the constructed FacetEnumerationImpl. We also need to 
construct it with a simple String, not a list. Then, when asked for the value, 
and given an atom bridge, use the pattern that's currently in the 
XMLSchemaConverter: baseType.validate(stringvalue, atomBrige). Probably need to 
clean up the XMLSchemaConverter stuff, too, since it's doing something odd.

We have to validate at parse time. But we can turn the validated list back into 
a single string.

Steps: change constructor to take the base type and a single String
value. Optionally, add an override with the frozen prefix resolver (for
the qname case). Add a member for the type. Optionally, add a member
for the resolver. Change the value member to be a single string instead
of an array. Uncomment toString(), return the now-single-string value
member. In getvalue, do baseType.validate() and return the result. Fix
the constructor call(s) in XMLSchemaConverter to match the changed
constructor signature(s).

Original issue reported on code.google.com by joe.bays...@gmail.com on 13 Sep 2012 at 5:40

[GoogleCodeExporter]

Original comment by joe.bays...@gmail.com on 26 Sep 2012 at 4:05

• Added labels: Milestone-Release1.0

[GoogleCodeExporter]

Following the above steps I have added 

return m_type.validate(...) interface method getValue of 
org.genxdm.xs.components.EnumerationDefinition now has to throw 
DatatypeException.

Which, in turn, means that it needs to get handled in 
SchemaConstraintChecker.checkSimpleType method. Following the practice in this 
class I catch that and throw a newly created exception that is derived from 
ComponentConstraintException. I also had to add an member to ValidationOutcome, 
list the part number from the spec...i.e. the whole thing.

Is this a right thing to do? If an enum valid does not to comply to the 
baseType than it would fail in XMLSchemaConverter. Can I presume that this is 
it and not bother with SchemaConstraintChecker? Is it possible that despite 
XMLSchemaConverter error the code in SchemaConstraintChecker still gets 
invoked? If not than I would simply throw an AssertionError and not add any 
ComponentConstraintException based exceptions.

I am attaching a patch for easy viewing....Note that it depends on my other 
changes so it wouldn't compile until they are committed (if they are 
committed). But it should be good enough for the purpose of illustration.

Original comment by yury.ska...@gmail.com on 18 Oct 2012 at 5:45

Attachments:

• enumConstraints.patch

[GoogleCodeExporter]

If there's going to be an exception, it's going to happen at parse time--the 
baseType.validate() still happens in XMLSchemaConverter, and should happen for 
any other construction method (one hopes).

Therefore, the possibility of the exception should be nil. Which means catch 
and return null, noting it as "never happen."

Of course, the rule for "never happen" in catch clauses is: you should always 
put your name, phone number, and time zone, so that if it ever does, someone 
can crank-call you at three AM ....

(I'm not going to do that, even though I'm never-happening it, with a comment)

Original comment by aale...@gmail.com on 24 Oct 2012 at 4:40

[GoogleCodeExporter]

This issue was closed by revision r403.

Original comment by aale...@gmail.com on 24 Oct 2012 at 4:56

• Changed state: Fixed