Home » Archived » XML Schema Definition (XSD) » XSDConstrainingFacet.isConstraintSatisfied
|
| Re: XSDConstrainingFacet.isConstraintSatisfied [message #56415 is a reply to message #56374] |
Tue, 28 December 2004 14:58   |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Klass,
Both the whitespace and pattern facets apply to the lexical space not
the value space. The whitespace facet isn't really even so much a
constraint as a way of handling the whitespace during parsing. I.e., it
isn't wrong to have a leading space in a string that will be handled in
collapse mode during a subsequent parse. (It isn't even wrong to have
spaces in values in a list, which will definitely parse differently
later!) Similarly, the pattern facet expects to be applied to the
literal during the parse not to the value. If you just did
value.toString() and used XSDSimpleTypeDefinition.isValidLiteral/assess
with that string, it would avoid doing all these detailed steps and the
special case logic. And, most importantly, it would force you to
consider how the value should be converted to a literal, since that
choice may affect validity.
Klaas Dellschaft wrote:
>Hi,
>
>I've been looking for a way to validate whether a value (not its lexical
>representation!) is contained in the value space of a type. I had a look at
>the interface definitions and saw the method
>XSDConstrainingFacet.isConstraintSatisfied(Object value) which seems to be
>made for this purpose.
>
>I'm trying to run this source code:
>
>--------------------------------------------
>
>boolean result = true;
>XSDEnumerationFacet enumeration = type2.getEffectiveEnumerationFacet();
>for (Iterator i = enumeration.getValue().iterator(); i.hasNext();) {
> Object value = i.next();
> for (Iterator j = type1.getFacets().iterator(); j.hasNext();) {
> XSDConstrainingFacet facet = (XSDConstrainingFacet) j.next();
> result = result && facet.isConstraintSatisfied(value);
> }
>}
>
>--------------------------------------------
>
>But now I'm discovering problems: For XSDWhiteSpaceFacet instances the
>method always returns false (which I didn't expect) and for XSDPatternFacets
>always a ClassCastExcpetion is thrown if I pass for example a BigDecimal as
>the value. I inserted the source code from XSDPatternFacetImpl.java below.
>
>
>---XSDPatternFacetImpl.java-----------------
>
>public boolean isConstraintSatisfied(Object value)
>{
> for (Iterator thePatterns = getPatterns(false).iterator();
> thePatterns.hasNext(); )
> {
> RegularExpression pattern = (RegularExpression)thePatterns.next();
> // In this if-condition a ClassCastException is thrown
> if (!pattern.matches((String)value))
> {
> return false;
> }
> }
> return true;
>}
>
>--------------------------------------------
>
>
>I think one possible solution would be to use "value.toString()" instead of
>"(String)value" or to return false if the object isn't a String.
>
>
>Cheers
>Klaas
>
>
>
>
|
|
| | |
| Re: XSDConstrainingFacet.isConstraintSatisfied [message #56495 is a reply to message #56442] |
Wed, 29 December 2004 13:47 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------010701090305000203090101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Klaas,
The string " 12345 " is a valid literal for xsd:int, so it would
seem odd for it to say it doesn't satisfy the whiteSpace constraint
wouldn't it? I know returning false always isn't all the useful either,
but neither would throwing an unsupported operation exception, which is
probably the "right" thing . Since the isConstraintSatisfied method
comes from XSDConstrainingFacet, having a version in XSDWhiteSpaceFacet
that takes a String probably would just go unnoticed.
Klaas Dellschaft wrote:
>>Both the whitespace and pattern facets apply to the lexical space not the
>>value space. The whitespace facet isn't really even so much a constraint
>>as a way of handling the whitespace during parsing. I.e., it isn't wrong
>>to have a leading space in a string that will be handled in collapse mode
>>during a subsequent parse.
>>
>>
>
>You are right. Both facets apply to the lexical representation of values.
>But the whiteSpace facet only has a bearing on the value space of Strings so
>I thought for all other types than Strings the whiteSpace constraint is
>always fulfilled by their values and not always unfulfilled.
>
>From my point of view even for Strings you can decide whether the given
>value is normalized according to the whiteSpace facet. For example if
>whiteSpace is set to "preserve" the given string is always in the value
>space of the type (according to the whiteSpace facet). If the whiteSpace is
>set to "replace" then the value space only contains strings which doesn't
>contain a tab, a line feed or carriage return. And for "collapse" only
>strings are valid which don't contain sequences of spaces.
>
>So if isConstraintSatisfied should return whether a value is in the value
>space of a type according to this facet then I didn't expect to get always
>false for the whiteSpace facet.
>
>
>
>
>>Similarly, the pattern facet expects to be applied to the literal during
>>the parse not to the value. If you just did value.toString() and used
>>XSDSimpleTypeDefinition.isValidLiteral/assess with that string, it would
>>avoid doing all these detailed steps and the special case logic. And,
>>most importantly, it would force you to consider how the value should be
>>converted to a literal, since that choice may affect validity.
>>
>>
>
>I used isConstraintSatisfied because I didn't want to consider how the value
>should be converted. I thought you have done that for me ;-) But I think
>throwing a ClassCastException is not the correct way to tell me that I have
>to pass a String if the parameter is Object.
>
>What is the intended usage of isConstraintSatisfied? Should I pass values
>from the value space or should I pass lexical representations? If a lexical
>representation should be passed then I think it would be better to change
>the parameter from Object to String (as it is the case for
>XSDSimpleTypeDefinition.isValidLiteral) and/or mention it in the JavaDoc
>that a lexical representation is expected.
>
>If a value from the value space is expected then also the pattern facet
>should expect such a value and not a lexical representation. But as you
>mentioned a value may have infinite representations in the lexical space.
>And even if only one lexical representation is matched by the pattern then
>its corresponding value is in the value space. So it would be impossible to
>decide whether a value from the value space fulfills the pattern constraint.
>
>
>Cheers
>Klaas
>
>
>
>
--------------010701090305000203090101
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Klaas,<br>
<br>
The string " 12345 " is a valid literal for xsd:int, so it would
seem odd for it to say it doesn't satisfy the whiteSpace constraint
wouldn't it? I know returning false always isn't all the useful
either, but neither would throwing an unsupported operation exception,
which is probably the "right" thing . Since the isConstraintSatisfied
method comes from XSDConstrainingFacet, having a version in
XSDWhiteSpaceFacet that takes a String probably would just go unnoticed.<br>
<br>
<br>
Klaas Dellschaft wrote:
<blockquote cite="midcqu1b7$89u$1@www.eclipse.org" type="cite">
<blockquote type="cite">
<pre wrap="">Both the whitespace and pattern facets apply to the lexical space not the
value space. The whitespace facet isn't really even so much a constraint
as a way of handling the whitespace during parsing. I.e., it isn't wrong
to have a leading space in a string that will be handled in collapse mode
during a subsequent parse.
</pre>
</blockquote>
<pre wrap=""><!---->
You are right. Both facets apply to the lexical representation of values.
But the whiteSpace facet only has a bearing on the value space of Strings so
I thought for all other types than Strings the whiteSpace constraint is
always fulfilled by their values and not always unfulfilled.
From my point of view even for Strings you can decide whether the given
value is normalized according to the whiteSpace facet. For example if
whiteSpace is set to "preserve" the given string is always in the value
space of the type (according to the whiteSpace facet). If the whiteSpace is
set to "replace" then the value space only contains strings which doesn't
contain a tab, a line feed or carriage return. And for "collapse" only
strings are valid which don't contain sequences of spaces.
So if isConstraintSatisfied should return whether a value is in the value
space of a type according to this facet then I didn't expect to get always
false for the whiteSpace facet.
</pre>
<blockquote type="cite">
<pre wrap="">Similarly, the pattern facet expects to be applied to the literal during
the parse not to the value. If you just did value.toString() and used
XSDSimpleTypeDefinition.isValidLiteral/assess with that string, it would
avoid doing all these detailed steps and the special case logic. And,
most importantly, it would force you to consider how the value should be
converted to a literal, since that choice may affect validity.
</pre>
</blockquote>
<pre wrap=""><!---->
I used isConstraintSatisfied because I didn't want to consider how the value
should be converted. I thought you have done that for me ;-) But I think
throwing a ClassCastException is not the correct way to tell me that I have
to pass a String if the parameter is Object.
What is the intended usage of isConstraintSatisfied? Should I pass values
from the value space or should I pass lexical representations? If a lexical
representation should be passed then I think it would be better to change
the parameter from Object to String (as it is the case for
XSDSimpleTypeDefinition.isValidLiteral) and/or mention it in the JavaDoc
that a lexical representation is expected.
If a value from the value space is expected then also the pattern facet
should expect such a value and not a lexical representation. But as you
mentioned a value may have infinite representations in the lexical space.
And even if only one lexical representation is matched by the pattern then
its corresponding value is in the value space. So it would be impossible to
decide whether a value from the value space fulfills the pattern constraint.
Cheers
Klaas
</pre>
</blockquote>
<br>
</body>
</html>
--------------010701090305000203090101--
|
|
|
| Re: XSDConstrainingFacet.isConstraintSatisfied [message #56522 is a reply to message #56469] |
Wed, 29 December 2004 13:47 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Klass,
Given an XSDEnumerationFacet, you can do
xsdEnumerationFacet.getSimpleTypeDefinition().getEnumeration Facets() to
get the list of concrete facet versions with their individual lexical
values. The same will work for XSDPatternFacet.
Klaas Dellschaft wrote:
>I answered the matters of principle in my other posting whether the
>isConstraintSatisfied expects a lexical representation or a value from the
>value space and whether a ClassCastException is such a good thing to point
>that out.
>
>
>But I still need a resolution for my problem: My main problem is that I
>don't get the lexical reprentations of values from an effective enumeration
>facet. It is only possible to get a list of values. If I call
>getLexicalValue on the effective enumeration facet then I get a single
>string which contains a comma separated list of values. And I think it would
>be impossible to split this list at the commas because what happens if one
>of the lexical values contains a comma?
>
>So from my point of view it would be good to add a new function to
>XSDRepeatableFacet which returns the list of lexical values. Even for the
>pattern facet this new method would ease the query. Although it isn't really
>needed because XSDPatternFacet.getValue() doesn't return RegEx-instances but
>the unparsed patterns.
>
>
>So my suggestion would be to add the following method to XSDRepeatableFacet:
>public EList getLexcialValues()
>
>
>Cheers
>Klaas
>
>
>
>
>
>
|
|
| | |
| Re: XSDConstrainingFacet.isConstraintSatisfied [message #56600 is a reply to message #56575] |
Wed, 29 December 2004 16:34 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------040401010802080905000705
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Klaas,
I understand what you are saying. Nevertheless, to me it seems
meaningless to check a constraint that is applicable only to the lexical
space given only a value in the value space. It also seems bad that
isConstraintSatisified would return a result that contradicts
isValidLiteral. In general, if you pass a type of value different from
the type expected by isConstraintSatisfied, you will get a class cast
exception. E.g., if you pass a String when a BigDecimal is expected.
It seems to me that using isValidLiteral with the literal (using
toString or whatever value to literal conversion you choose to use)
pretty much does everything you want. If you use assess, you can even
check if the normalized literal is the same as the original literal,
i.e., whether white space processing changed the input string. And you
can get translated error messages indicating which constraints aren't
satisfied and why.
Klaas Dellschaft wrote:
>>The string " 12345 " is a valid literal for xsd:int, so it would seem
>>odd for it to say it doesn't satisfy the whiteSpace constraint wouldn't
>>it?
>>I know returning false always isn't all the useful either, but neither
>>would
>>throwing an unsupported operation exception, which is probably the "right"
>>thing . Since the isConstraintSatisfied method comes from
>>XSDConstrainingFacet, having a version in XSDWhiteSpaceFacet that takes a
>>String probably would just go unnoticed.
>>
>>
>
>Certainly it is a valid literal but it isn't a valid value from the value
>space (because numbers don't contain whiteSpaces). If you want to check the
>constraint of an xsd:int-value I expected you wouldn't pass a String but a
>BigDecimal-instance.
>
>From my point of view the main question is whether you expect a value from
>the value space or a literal representation. Becaus the parameter has the
>type Object I thought you would expect a value from the value space. And in
>the JavaDoc you say "Returns whether the given value satisfies the
>constraint of this facet". In the JavaDoc if you mean the literal
>representation you normally speek about the "literal" and not about the
>"value". And normally you use String as a parameter and not Object if you
>expect a literal.
>
>
>Did you read the last paragraphs in my previous posting about the
>ClassCastException which was thrown by XSDPatternFacet? It is thrown when I
>pass a BigDecimal-instance instead of a String. It is a little bit hidden
>below a cited paragraph from your own answer.
>
>
>Cheers
>Klaas
>
>
>
>
--------------040401010802080905000705
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Klaas,<br>
<br>
I understand what you are saying. Nevertheless, to me it seems
meaningless to check a constraint that is applicable only to the
lexical space given only a value in the value space. It also seems bad
that isConstraintSatisified would return a result that contradicts
isValidLiteral. In general, if you pass a type of value different
from the type expected by isConstraintSatisfied, you will get a class
cast exception. E.g., if you pass a String when a BigDecimal is
expected. <br>
<br>
It seems to me that using isValidLiteral with the literal (using
toString or whatever value to literal conversion you choose to use)
pretty much does everything you want. If you use assess, you can even
check if the normalized literal is the same as the original literal,
i.e., whether white space processing changed the input string. And you
can get translated error messages indicating which constraints aren't
satisfied and why.<br>
<br>
<br>
Klaas Dellschaft wrote:
<blockquote cite="midcqui6o$t4b$1@www.eclipse.org" type="cite">
<blockquote type="cite">
<pre wrap="">The string " 12345 " is a valid literal for xsd:int, so it would seem
odd for it to say it doesn't satisfy the whiteSpace constraint wouldn't
it?
I know returning false always isn't all the useful either, but neither
would
throwing an unsupported operation exception, which is probably the "right"
thing . Since the isConstraintSatisfied method comes from
XSDConstrainingFacet, having a version in XSDWhiteSpaceFacet that takes a
String probably would just go unnoticed.
</pre>
</blockquote>
<pre wrap=""><!---->
Certainly it is a valid literal but it isn't a valid value from the value
space (because numbers don't contain whiteSpaces). If you want to check the
constraint of an xsd:int-value I expected you wouldn't pass a String but a
BigDecimal-instance.
From my point of view the main question is whether you expect a value from
the value space or a literal representation. Becaus the parameter has the
type Object I thought you would expect a value from the value space. And in
the JavaDoc you say "Returns whether the given value satisfies the
constraint of this facet". In the JavaDoc if you mean the literal
representation you normally speek about the "literal" and not about the
"value". And normally you use String as a parameter and not Object if you
expect a literal.
Did you read the last paragraphs in my previous posting about the
ClassCastException which was thrown by XSDPatternFacet? It is thrown when I
pass a BigDecimal-instance instead of a String. It is a little bit hidden
below a cited paragraph from your own answer.
Cheers
Klaas
</pre>
</blockquote>
<br>
</body>
</html>
--------------040401010802080905000705--
|
|
|
| Re: XSDConstrainingFacet.isConstraintSatisfied [message #56627 is a reply to message #56548] |
Wed, 29 December 2004 16:38 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------040005080105010803000901
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Klaas,
The getSimpleTypeDefinition will return the simple type that synthesized
the facet, which will also be the simple type that introduced the
original facets in the first place, so they will be there for that
derivation step. Enumeration facets don't accumulate via inheritance so
a derived enumeration completely replaces the base enumeration.
Klaas Dellschaft wrote:
>>Given an XSDEnumerationFacet, you can do
>> xsdEnumerationFacet.getSimpleTypeDefinition().getEnumeration Facets() to
>>get the list of concrete facet versions with their individual lexical
>>values. The same will work for XSDPatternFacet.
>>
>>
>
>But do I also get the inherited enumeration facet or does it also contain a
>facet if it was defined in an earlier derivation step? Because in the
>JavaDoc it is said that it represents the enumeration facet from facet
>contents and I thought in the facet contents you only find the facets from
>the current derivation step.
>
>Klaas
>
>
>
>
--------------040005080105010803000901
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Klaas,<br>
<br>
The getSimpleTypeDefinition will return the simple type that
synthesized the facet, which will also be the simple type that
introduced the original facets in the first place, so they will be
there for that derivation step. Enumeration facets don't accumulate
via inheritance so a derived enumeration completely replaces the base
enumeration.<br>
<br>
<br>
Klaas Dellschaft wrote:
<blockquote cite="midcquh8a$q4m$1@www.eclipse.org" type="cite">
<blockquote type="cite">
<pre wrap="">Given an XSDEnumerationFacet, you can do
xsdEnumerationFacet.getSimpleTypeDefinition().getEnumeration Facets() to
get the list of concrete facet versions with their individual lexical
values. The same will work for XSDPatternFacet.
</pre>
</blockquote>
<pre wrap=""><!---->
But do I also get the inherited enumeration facet or does it also contain a
facet if it was defined in an earlier derivation step? Because in the
JavaDoc it is said that it represents the enumeration facet from facet
contents and I thought in the facet contents you only find the facets from
the current derivation step.
Klaas
</pre>
</blockquote>
<br>
</body>
</html>
--------------040005080105010803000901--
|
|
| | |
| Re: XSDConstrainingFacet.isConstraintSatisfied [message #56734 is a reply to message #56680] |
Thu, 30 December 2004 13:11 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------070107090108080806060203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Klaas,
There's definitely room to improve the documentation. Even the fact
that the literal needs to be normalized before the pattern is applied
should be made clear.
Klaas Dellschaft wrote:
>>I understand what you are saying. Nevertheless, to me it seems
>>meaningless
>>to check a constraint that is applicable only to the lexical space given
>>only a value in the value space. It also seems bad that
>>isConstraintSatisified would return a result that contradicts
>>isValidLiteral. In general, if you pass a type of value different from
>>the
>>type expected by isConstraintSatisfied, you will get a class cast
>>exception. E.g., if you pass a String when a BigDecimal is expected.
>>
>>
>
>And I understand what you are saying ;-) But I was surprised because one and
>the same method sometimes expects a value from the value space and sometimes
>a lexical representation. That wasn't obvious to me after reading the
>JavaDoc.
>
>For me all signs (using the term "value" in the description + getting an
>Object parameter) indicated that always a value was expected. Even the
>naming of the parameter was an additional hint to me. A ClassCastException
>wasn't expected by me, too. An Object was expected and an appropriate Object
>was passed by me (BigDecimal for a type derived from xs:decimal). And an
>uncaught exception isn't the best what can happen in applications ;-) So
>probably we can agree to improve the documentation of isConstraintSatisfied?
>
>An alternative would be to change the paramter to String and always expect a
>lexical representation. In this way the method always behaves in the same
>way and no ClassCastException would appear at pattern facets. But
>
>
>Klaas
>
>
>
>
--------------070107090108080806060203
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Klaas,<br>
<br>
There's definitely room to improve the documentation. Even the fact
that the literal needs to be normalized before the pattern is applied
should be made clear. <br>
<br>
<br>
Klaas Dellschaft wrote:
<blockquote cite="midcqur6m$pjo$1@www.eclipse.org" type="cite">
<blockquote type="cite">
<pre wrap="">I understand what you are saying. Nevertheless, to me it seems
meaningless
to check a constraint that is applicable only to the lexical space given
only a value in the value space. It also seems bad that
isConstraintSatisified would return a result that contradicts
isValidLiteral. In general, if you pass a type of value different from
the
type expected by isConstraintSatisfied, you will get a class cast
exception. E.g., if you pass a String when a BigDecimal is expected.
</pre>
</blockquote>
<pre wrap=""><!---->
And I understand what you are saying ;-) But I was surprised because one and
the same method sometimes expects a value from the value space and sometimes
a lexical representation. That wasn't obvious to me after reading the
JavaDoc.
For me all signs (using the term "value" in the description + getting an
Object parameter) indicated that always a value was expected. Even the
naming of the parameter was an additional hint to me. A ClassCastException
wasn't expected by me, too. An Object was expected and an appropriate Object
was passed by me (BigDecimal for a type derived from xs:decimal). And an
uncaught exception isn't the best what can happen in applications ;-) So
probably we can agree to improve the documentation of isConstraintSatisfied?
An alternative would be to change the paramter to String and always expect a
lexical representation. In this way the method always behaves in the same
way and no ClassCastException would appear at pattern facets. But
Klaas
</pre>
</blockquote>
<br>
</body>
</html>
--------------070107090108080806060203--
|
|
|
| Re: XSDConstrainingFacet.isConstraintSatisfied [message #593212 is a reply to message #56374] |
Tue, 28 December 2004 14:58 |
 Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Klass,
Both the whitespace and pattern facets apply to the lexical space not
the value space. The whitespace facet isn't really even so much a
constraint as a way of handling the whitespace during parsing. I.e., it
isn't wrong to have a leading space in a string that will be handled in
collapse mode during a subsequent parse. (It isn't even wrong to have
spaces in values in a list, which will definitely parse differently
later!) Similarly, the pattern facet expects to be applied to the
literal during the parse not to the value. If you just did
value.toString() and used XSDSimpleTypeDefinition.isValidLiteral/assess
with that string, it would avoid doing all these detailed steps and the
special case logic. And, most importantly, it would force you to
consider how the value should be converted to a literal, since that
choice may affect validity.
Klaas Dellschaft wrote:
>Hi,
>
>I've been looking for a way to validate whether a value (not its lexical
>representation!) is contained in the value space of a type. I had a look at
>the interface definitions and saw the method
>XSDConstrainingFacet.isConstraintSatisfied(Object value) which seems to be
>made for this purpose.
>
>I'm trying to run this source code:
>
>--------------------------------------------
>
>boolean result = true;
>XSDEnumerationFacet enumeration = type2.getEffectiveEnumerationFacet();
>for (Iterator i = enumeration.getValue().iterator(); i.hasNext();) {
> Object value = i.next();
> for (Iterator j = type1.getFacets().iterator(); j.hasNext();) {
> XSDConstrainingFacet facet = (XSDConstrainingFacet) j.next();
> result = result && facet.isConstraintSatisfied(value);
> }
>}
>
>--------------------------------------------
>
>But now I'm discovering problems: For XSDWhiteSpaceFacet instances the
>method always returns false (which I didn't expect) and for XSDPatternFacets
>always a ClassCastExcpetion is thrown if I pass for example a BigDecimal as
>the value. I inserted the source code from XSDPatternFacetImpl.java below.
>
>
>---XSDPatternFacetImpl.java-----------------
>
>public boolean isConstraintSatisfied(Object value)
>{
> for (Iterator thePatterns = getPatterns(false).iterator();
> thePatterns.hasNext(); )
> {
> RegularExpression pattern = (RegularExpression)thePatterns.next();
> // In this if-condition a ClassCastException is thrown
> if (!pattern.matches((String)value))
> {
> return false;
> }
> }
> return true;
>}
>
>--------------------------------------------
>
>
>I think one possible solution would be to use "value.toString()" instead of
>"(String)value" or to return false if the object isn't a String.
>
>
>Cheers
>Klaas
>
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: XSDConstrainingFacet.isConstraintSatisfied [message #593249 is a reply to message #56442] |
Wed, 29 December 2004 13:47 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------010701090305000203090101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Klaas,
The string " 12345 " is a valid literal for xsd:int, so it would
seem odd for it to say it doesn't satisfy the whiteSpace constraint
wouldn't it? I know returning false always isn't all the useful either,
but neither would throwing an unsupported operation exception, which is
probably the "right" thing . Since the isConstraintSatisfied method
comes from XSDConstrainingFacet, having a version in XSDWhiteSpaceFacet
that takes a String probably would just go unnoticed.
Klaas Dellschaft wrote:
>>Both the whitespace and pattern facets apply to the lexical space not the
>>value space. The whitespace facet isn't really even so much a constraint
>>as a way of handling the whitespace during parsing. I.e., it isn't wrong
>>to have a leading space in a string that will be handled in collapse mode
>>during a subsequent parse.
>>
>>
>
>You are right. Both facets apply to the lexical representation of values.
>But the whiteSpace facet only has a bearing on the value space of Strings so
>I thought for all other types than Strings the whiteSpace constraint is
>always fulfilled by their values and not always unfulfilled.
>
>From my point of view even for Strings you can decide whether the given
>value is normalized according to the whiteSpace facet. For example if
>whiteSpace is set to "preserve" the given string is always in the value
>space of the type (according to the whiteSpace facet). If the whiteSpace is
>set to "replace" then the value space only contains strings which doesn't
>contain a tab, a line feed or carriage return. And for "collapse" only
>strings are valid which don't contain sequences of spaces.
>
>So if isConstraintSatisfied should return whether a value is in the value
>space of a type according to this facet then I didn't expect to get always
>false for the whiteSpace facet.
>
>
>
>
>>Similarly, the pattern facet expects to be applied to the literal during
>>the parse not to the value. If you just did value.toString() and used
>>XSDSimpleTypeDefinition.isValidLiteral/assess with that string, it would
>>avoid doing all these detailed steps and the special case logic. And,
>>most importantly, it would force you to consider how the value should be
>>converted to a literal, since that choice may affect validity.
>>
>>
>
>I used isConstraintSatisfied because I didn't want to consider how the value
>should be converted. I thought you have done that for me ;-) But I think
>throwing a ClassCastException is not the correct way to tell me that I have
>to pass a String if the parameter is Object.
>
>What is the intended usage of isConstraintSatisfied? Should I pass values
>from the value space or should I pass lexical representations? If a lexical
>representation should be passed then I think it would be better to change
>the parameter from Object to String (as it is the case for
>XSDSimpleTypeDefinition.isValidLiteral) and/or mention it in the JavaDoc
>that a lexical representation is expected.
>
>If a value from the value space is expected then also the pattern facet
>should expect such a value and not a lexical representation. But as you
>mentioned a value may have infinite representations in the lexical space.
>And even if only one lexical representation is matched by the pattern then
>its corresponding value is in the value space. So it would be impossible to
>decide whether a value from the value space fulfills the pattern constraint.
>
>
>Cheers
>Klaas
>
>
>
>
--------------010701090305000203090101
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Klaas,<br>
<br>
The string " 12345 " is a valid literal for xsd:int, so it would
seem odd for it to say it doesn't satisfy the whiteSpace constraint
wouldn't it? I know returning false always isn't all the useful
either, but neither would throwing an unsupported operation exception,
which is probably the "right" thing . Since the isConstraintSatisfied
method comes from XSDConstrainingFacet, having a version in
XSDWhiteSpaceFacet that takes a String probably would just go unnoticed.<br>
<br>
<br>
Klaas Dellschaft wrote:
<blockquote cite="midcqu1b7$89u$1@www.eclipse.org" type="cite">
<blockquote type="cite">
<pre wrap="">Both the whitespace and pattern facets apply to the lexical space not the
value space. The whitespace facet isn't really even so much a constraint
as a way of handling the whitespace during parsing. I.e., it isn't wrong
to have a leading space in a string that will be handled in collapse mode
during a subsequent parse.
</pre>
</blockquote>
<pre wrap=""><!---->
You are right. Both facets apply to the lexical representation of values.
But the whiteSpace facet only has a bearing on the value space of Strings so
I thought for all other types than Strings the whiteSpace constraint is
always fulfilled by their values and not always unfulfilled.
From my point of view even for Strings you can decide whether the given
value is normalized according to the whiteSpace facet. For example if
whiteSpace is set to "preserve" the given string is always in the value
space of the type (according to the whiteSpace facet). If the whiteSpace is
set to "replace" then the value space only contains strings which doesn't
contain a tab, a line feed or carriage return. And for "collapse" only
strings are valid which don't contain sequences of spaces.
So if isConstraintSatisfied should return whether a value is in the value
space of a type according to this facet then I didn't expect to get always
false for the whiteSpace facet.
</pre>
<blockquote type="cite">
<pre wrap="">Similarly, the pattern facet expects to be applied to the literal during
the parse not to the value. If you just did value.toString() and used
XSDSimpleTypeDefinition.isValidLiteral/assess with that string, it would
avoid doing all these detailed steps and the special case logic. And,
most importantly, it would force you to consider how the value should be
converted to a literal, since that choice may affect validity.
</pre>
</blockquote>
<pre wrap=""><!---->
I used isConstraintSatisfied because I didn't want to consider how the value
should be converted. I thought you have done that for me ;-) But I think
throwing a ClassCastException is not the correct way to tell me that I have
to pass a String if the parameter is Object.
What is the intended usage of isConstraintSatisfied? Should I pass values
from the value space or should I pass lexical representations? If a lexical
representation should be passed then I think it would be better to change
the parameter from Object to String (as it is the case for
XSDSimpleTypeDefinition.isValidLiteral) and/or mention it in the JavaDoc
that a lexical representation is expected.
If a value from the value space is expected then also the pattern facet
should expect such a value and not a lexical representation. But as you
mentioned a value may have infinite representations in the lexical space.
And even if only one lexical representation is matched by the pattern then
its corresponding value is in the value space. So it would be impossible to
decide whether a value from the value space fulfills the pattern constraint.
Cheers
Klaas
</pre>
</blockquote>
<br>
</body>
</html>
--------------010701090305000203090101--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: XSDConstrainingFacet.isConstraintSatisfied [message #593270 is a reply to message #56469] |
Wed, 29 December 2004 13:47 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Klass,
Given an XSDEnumerationFacet, you can do
xsdEnumerationFacet.getSimpleTypeDefinition().getEnumeration Facets() to
get the list of concrete facet versions with their individual lexical
values. The same will work for XSDPatternFacet.
Klaas Dellschaft wrote:
>I answered the matters of principle in my other posting whether the
>isConstraintSatisfied expects a lexical representation or a value from the
>value space and whether a ClassCastException is such a good thing to point
>that out.
>
>
>But I still need a resolution for my problem: My main problem is that I
>don't get the lexical reprentations of values from an effective enumeration
>facet. It is only possible to get a list of values. If I call
>getLexicalValue on the effective enumeration facet then I get a single
>string which contains a comma separated list of values. And I think it would
>be impossible to split this list at the commas because what happens if one
>of the lexical values contains a comma?
>
>So from my point of view it would be good to add a new function to
>XSDRepeatableFacet which returns the list of lexical values. Even for the
>pattern facet this new method would ease the query. Although it isn't really
>needed because XSDPatternFacet.getValue() doesn't return RegEx-instances but
>the unparsed patterns.
>
>
>So my suggestion would be to add the following method to XSDRepeatableFacet:
>public EList getLexcialValues()
>
>
>Cheers
>Klaas
>
>
>
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: XSDConstrainingFacet.isConstraintSatisfied [message #593308 is a reply to message #56575] |
Wed, 29 December 2004 16:34 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------040401010802080905000705
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Klaas,
I understand what you are saying. Nevertheless, to me it seems
meaningless to check a constraint that is applicable only to the lexical
space given only a value in the value space. It also seems bad that
isConstraintSatisified would return a result that contradicts
isValidLiteral. In general, if you pass a type of value different from
the type expected by isConstraintSatisfied, you will get a class cast
exception. E.g., if you pass a String when a BigDecimal is expected.
It seems to me that using isValidLiteral with the literal (using
toString or whatever value to literal conversion you choose to use)
pretty much does everything you want. If you use assess, you can even
check if the normalized literal is the same as the original literal,
i.e., whether white space processing changed the input string. And you
can get translated error messages indicating which constraints aren't
satisfied and why.
Klaas Dellschaft wrote:
>>The string " 12345 " is a valid literal for xsd:int, so it would seem
>>odd for it to say it doesn't satisfy the whiteSpace constraint wouldn't
>>it?
>>I know returning false always isn't all the useful either, but neither
>>would
>>throwing an unsupported operation exception, which is probably the "right"
>>thing . Since the isConstraintSatisfied method comes from
>>XSDConstrainingFacet, having a version in XSDWhiteSpaceFacet that takes a
>>String probably would just go unnoticed.
>>
>>
>
>Certainly it is a valid literal but it isn't a valid value from the value
>space (because numbers don't contain whiteSpaces). If you want to check the
>constraint of an xsd:int-value I expected you wouldn't pass a String but a
>BigDecimal-instance.
>
>From my point of view the main question is whether you expect a value from
>the value space or a literal representation. Becaus the parameter has the
>type Object I thought you would expect a value from the value space. And in
>the JavaDoc you say "Returns whether the given value satisfies the
>constraint of this facet". In the JavaDoc if you mean the literal
>representation you normally speek about the "literal" and not about the
>"value". And normally you use String as a parameter and not Object if you
>expect a literal.
>
>
>Did you read the last paragraphs in my previous posting about the
>ClassCastException which was thrown by XSDPatternFacet? It is thrown when I
>pass a BigDecimal-instance instead of a String. It is a little bit hidden
>below a cited paragraph from your own answer.
>
>
>Cheers
>Klaas
>
>
>
>
--------------040401010802080905000705
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Klaas,<br>
<br>
I understand what you are saying. Nevertheless, to me it seems
meaningless to check a constraint that is applicable only to the
lexical space given only a value in the value space. It also seems bad
that isConstraintSatisified would return a result that contradicts
isValidLiteral. In general, if you pass a type of value different
from the type expected by isConstraintSatisfied, you will get a class
cast exception. E.g., if you pass a String when a BigDecimal is
expected. <br>
<br>
It seems to me that using isValidLiteral with the literal (using
toString or whatever value to literal conversion you choose to use)
pretty much does everything you want. If you use assess, you can even
check if the normalized literal is the same as the original literal,
i.e., whether white space processing changed the input string. And you
can get translated error messages indicating which constraints aren't
satisfied and why.<br>
<br>
<br>
Klaas Dellschaft wrote:
<blockquote cite="midcqui6o$t4b$1@www.eclipse.org" type="cite">
<blockquote type="cite">
<pre wrap="">The string " 12345 " is a valid literal for xsd:int, so it would seem
odd for it to say it doesn't satisfy the whiteSpace constraint wouldn't
it?
I know returning false always isn't all the useful either, but neither
would
throwing an unsupported operation exception, which is probably the "right"
thing . Since the isConstraintSatisfied method comes from
XSDConstrainingFacet, having a version in XSDWhiteSpaceFacet that takes a
String probably would just go unnoticed.
</pre>
</blockquote>
<pre wrap=""><!---->
Certainly it is a valid literal but it isn't a valid value from the value
space (because numbers don't contain whiteSpaces). If you want to check the
constraint of an xsd:int-value I expected you wouldn't pass a String but a
BigDecimal-instance.
From my point of view the main question is whether you expect a value from
the value space or a literal representation. Becaus the parameter has the
type Object I thought you would expect a value from the value space. And in
the JavaDoc you say "Returns whether the given value satisfies the
constraint of this facet". In the JavaDoc if you mean the literal
representation you normally speek about the "literal" and not about the
"value". And normally you use String as a parameter and not Object if you
expect a literal.
Did you read the last paragraphs in my previous posting about the
ClassCastException which was thrown by XSDPatternFacet? It is thrown when I
pass a BigDecimal-instance instead of a String. It is a little bit hidden
below a cited paragraph from your own answer.
Cheers
Klaas
</pre>
</blockquote>
<br>
</body>
</html>
--------------040401010802080905000705--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: XSDConstrainingFacet.isConstraintSatisfied [message #593336 is a reply to message #56548] |
Wed, 29 December 2004 16:38 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------040005080105010803000901
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Klaas,
The getSimpleTypeDefinition will return the simple type that synthesized
the facet, which will also be the simple type that introduced the
original facets in the first place, so they will be there for that
derivation step. Enumeration facets don't accumulate via inheritance so
a derived enumeration completely replaces the base enumeration.
Klaas Dellschaft wrote:
>>Given an XSDEnumerationFacet, you can do
>> xsdEnumerationFacet.getSimpleTypeDefinition().getEnumeration Facets() to
>>get the list of concrete facet versions with their individual lexical
>>values. The same will work for XSDPatternFacet.
>>
>>
>
>But do I also get the inherited enumeration facet or does it also contain a
>facet if it was defined in an earlier derivation step? Because in the
>JavaDoc it is said that it represents the enumeration facet from facet
>contents and I thought in the facet contents you only find the facets from
>the current derivation step.
>
>Klaas
>
>
>
>
--------------040005080105010803000901
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Klaas,<br>
<br>
The getSimpleTypeDefinition will return the simple type that
synthesized the facet, which will also be the simple type that
introduced the original facets in the first place, so they will be
there for that derivation step. Enumeration facets don't accumulate
via inheritance so a derived enumeration completely replaces the base
enumeration.<br>
<br>
<br>
Klaas Dellschaft wrote:
<blockquote cite="midcquh8a$q4m$1@www.eclipse.org" type="cite">
<blockquote type="cite">
<pre wrap="">Given an XSDEnumerationFacet, you can do
xsdEnumerationFacet.getSimpleTypeDefinition().getEnumeration Facets() to
get the list of concrete facet versions with their individual lexical
values. The same will work for XSDPatternFacet.
</pre>
</blockquote>
<pre wrap=""><!---->
But do I also get the inherited enumeration facet or does it also contain a
facet if it was defined in an earlier derivation step? Because in the
JavaDoc it is said that it represents the enumeration facet from facet
contents and I thought in the facet contents you only find the facets from
the current derivation step.
Klaas
</pre>
</blockquote>
<br>
</body>
</html>
--------------040005080105010803000901--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: XSDConstrainingFacet.isConstraintSatisfied [message #593399 is a reply to message #56680] |
Thu, 30 December 2004 13:11 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------070107090108080806060203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Klaas,
There's definitely room to improve the documentation. Even the fact
that the literal needs to be normalized before the pattern is applied
should be made clear.
Klaas Dellschaft wrote:
>>I understand what you are saying. Nevertheless, to me it seems
>>meaningless
>>to check a constraint that is applicable only to the lexical space given
>>only a value in the value space. It also seems bad that
>>isConstraintSatisified would return a result that contradicts
>>isValidLiteral. In general, if you pass a type of value different from
>>the
>>type expected by isConstraintSatisfied, you will get a class cast
>>exception. E.g., if you pass a String when a BigDecimal is expected.
>>
>>
>
>And I understand what you are saying ;-) But I was surprised because one and
>the same method sometimes expects a value from the value space and sometimes
>a lexical representation. That wasn't obvious to me after reading the
>JavaDoc.
>
>For me all signs (using the term "value" in the description + getting an
>Object parameter) indicated that always a value was expected. Even the
>naming of the parameter was an additional hint to me. A ClassCastException
>wasn't expected by me, too. An Object was expected and an appropriate Object
>was passed by me (BigDecimal for a type derived from xs:decimal). And an
>uncaught exception isn't the best what can happen in applications ;-) So
>probably we can agree to improve the documentation of isConstraintSatisfied?
>
>An alternative would be to change the paramter to String and always expect a
>lexical representation. In this way the method always behaves in the same
>way and no ClassCastException would appear at pattern facets. But
>
>
>Klaas
>
>
>
>
--------------070107090108080806060203
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Klaas,<br>
<br>
There's definitely room to improve the documentation. Even the fact
that the literal needs to be normalized before the pattern is applied
should be made clear. <br>
<br>
<br>
Klaas Dellschaft wrote:
<blockquote cite="midcqur6m$pjo$1@www.eclipse.org" type="cite">
<blockquote type="cite">
<pre wrap="">I understand what you are saying. Nevertheless, to me it seems
meaningless
to check a constraint that is applicable only to the lexical space given
only a value in the value space. It also seems bad that
isConstraintSatisified would return a result that contradicts
isValidLiteral. In general, if you pass a type of value different from
the
type expected by isConstraintSatisfied, you will get a class cast
exception. E.g., if you pass a String when a BigDecimal is expected.
</pre>
</blockquote>
<pre wrap=""><!---->
And I understand what you are saying ;-) But I was surprised because one and
the same method sometimes expects a value from the value space and sometimes
a lexical representation. That wasn't obvious to me after reading the
JavaDoc.
For me all signs (using the term "value" in the description + getting an
Object parameter) indicated that always a value was expected. Even the
naming of the parameter was an additional hint to me. A ClassCastException
wasn't expected by me, too. An Object was expected and an appropriate Object
was passed by me (BigDecimal for a type derived from xs:decimal). And an
uncaught exception isn't the best what can happen in applications ;-) So
probably we can agree to improve the documentation of isConstraintSatisfied?
An alternative would be to change the paramter to String and always expect a
lexical representation. In this way the method always behaves in the same
way and no ClassCastException would appear at pattern facets. But
Klaas
</pre>
</blockquote>
<br>
</body>
</html>
--------------070107090108080806060203--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 15:54:06 GMT 2024
Powered by FUDForum. Page generated in 0.04984 seconds |
] 
Search
Help
Register
Login
Home
