PSVI ramblings

Subjects

•	Home
•	VOTE Move XML Commons to Xerces
•	Commented: (XERCESJ 589) Bug with pattern restriction on long strings
•	: Xerces J 2 8 1 Release on Wednesday, September 13th
•	: Xerces J 2 9 0 Release on Wednesday, November 22nd
•	Commented: (XERCESJ 1066) Restriction+choice+substitutionGroup error
•	Commented: (XERCESJ 1178) Error getting prefix for an attribute with no n
•	Updated: (XERCESJ 1244) XMLSchemaValidator does not contribute element 's
•	Some consideration about the xerces DOM implementation
•	Updated: (XERCESJ 1066) Restriction+choice+substitutionGroup error
•	Commented: (XERCESJ 1227) Poor performance / OutOfMemoryError for sequenc
•	retain exception stack traces
•	Updated: (XERCESJ 1193) NPE or hang when parsing using the "continue afte
•	Future of NekoHTML
•	Commented: (XERCESJ 1203) NPE in XMLDTDProcessor
•	DOM Level 3 APIs for Xalan J and a new Xalan release (2 7 1)
•	: xml commons external 1 3 04 Release on Wednesday, November 22nd
•	Commented: (XERCESJ 1247) Incorrect location information on SAX when usin
•	XInclude exceptions how to mirror Xerces J functionality into Xerces C++?
•	First proposal on SoC project "Add support for the StAX (JSR 173) cursor API
•	: xml commons resolver 1 2 Release on Wednesday, November 22nd
•	Typo in RangeToken java Please check
•	Validator features
•	java lang ClassCastException when adopting Node
•	using the org apache xerces impl xs identity package
•	Updated: (XERCESJ 1257) buffer overflow in UTF8Reader for characters out
•	Problem with ref attributes and schema validation
•	Updated: (XERCESJ 122) XMLSchemaValidator does not contribute element 's d
•	Performance problem under load Xerces with Weblogic 9 x
•	remove ignored memory allocation
•	Commented: (XERCESJ 1177) SAXXMLStreamReader doesn 't always report namesp
•	Commented: (XERCESJ 977) Null pointer exception during DOM parsing
•	Commented: (XERCESJ 1197) Code cleanup for org apache xml serialize
•	Commented: (XERCESJ 1201) Initial contribution for StAX Event API
•	Updated: (XERCESJ 1061) Regex "$ " and "^ " characters treated as special c
•	Commented: (XERCESJ 1199) SAXXMLStreamReader should attempt to register a
•	Commented: (XERCESJ 1061) Regex "$ " and "^ " characters treated as special
•	Updated: (XERCESJ 589) Bug with pattern restriction on long strings
•	StackOverflow
•	xerces Range unnecessarily not garbage collectable if not detached
•	Updated: (XERCESJ 1178) Error getting prefix for an attribute with no nam
•	Bug in xs:redefine
•	Commented: (XERCESJ 1204) Can not set XMLEntityResolver for LSParser
•	Updated: (XERCESJ 1253) Prototype for SoC2007 project "Add support for th
•	Updated: (XERCESJ 1259) Add SteamFilter Function to SoC2007 project "Add
•	Assigned: (XERCESJ 444) SAXException thrown by EntityResolver is reported
•	Google Summer of Code 2007
•	Xerces J and XInclude relative path issue
•	Assigned: (XERCESJ 206) Stack overflow when using a schema validation
•	Commented: (XERCESJ 1215) Restrictions involving two levels of substituti
•	Closed: (XERCESJ 1203) NPE in XMLDTDProcessor
•	non overriding equals methoda
•	Resolved: (XERCESJ 1079) invalid value returned for TOTALDIGITS facet in
•	Xerces AS3 port
•	Updated: (XERCESJ 325) Regular Expression; Pattern "\| " clause order de
•	Updated: (XERCESJ 1196) Javadoc generation fails on Java SE 5 0
•	Closed: (XERCESJ 1202) DTD validation on XIncluded documents when the sch
•	Created: (XERCESJ 1124) Nonspecific schema error message
•	a bug in xerces
•	Updated: (XERCESJ 1201) Initial contribution for StAX Event API
•	Closed: (XERCESJ 1254) Empty uris in targetNamespace attribute not report

Links

Home

Oracle database error code

PSVI ramblings

PSVI ramblings

2003-08-27 - By Thomas Cox

Reply: 1 2

I have to use org.apache.xerces.impl.xs.psvi.* pretty heavily in production
software, and I just wanted to post some musings and perhaps a wistful question
.

The PSVI APIs seem to be fairly crufty. (Please don't take this as a rant. OK,
maybe a friendly rant... ;-) Of course, having spent far too much dealing with
the XML Schema spec, I have a great deal of sympathy for why that is the case.
I also understand it's in the "impl" set of packages, with limited support, but
it's the only game in town. (For me anyway - I don't know if it's better or not
, but I can't use http://www.eclipse.org/xsd/ due to licensing issues.)

Here's my "do-it-yourself" analogy: Let's say I need a left-handed metric wing
-nut. I know I've probably got one in a Mason jar in the garage, so I put down
my tools, go out, dump the jar on my workbench, poke through it until I finally
find what I need, rake the parts back into the jar, and go back to work.

That's what PSVI feel like to me. It's especially poignant when I'm staring at
the data I need in the debugger but it takes an extra hour to figure out all
the API hooks to look it up. It's not that big an issue if you only use it
occasionally, but it's not so great for frequent use. (Mind you, I'm VERY
thankful I don't have to make a left-handed metric wing-net from scratch. ;-)

Here's an example: I'm traipsing through a schema, and want to find out if this
element has an associated enumeration. I've already looked up the type def, so
I call -

static private ArrayList getEnumFacet(XSTypeDefinition xstd)
{
ArrayList enum = null;
if (xstd != null && xstd instanceof XSSimpleTypeDefinition)
{
XSSimpleTypeDefinition xsstd = (XSSimpleTypeDefinition)xstd;
XSObjectList xsol = xsstd.getMultiValueFacets();
if (xsol != null)
{
for (int f = 0; f < xsol.getLength(); ++f)
{
XSObject xob = xsol.item(f);
if (xob instanceof XSMultiValueFacet)
{
XSMultiValueFacet xsmvf = (XSMultiValueFacet)xob;
if (xsmvf.getFacetKind() == XSSimpleTypeDefinition
.FACET_ENUMERATION)
{
enum = new ArrayList();
StringList vals = xsmvf.getLexicalFacetValues();
for (int v = 0; v < vals.getLength(); ++v)
{
enum.add(vals.item(v));
}
}
}
}
}
}
return enum;
}

Well, OK; I got my enumeration back, so I'm fairly happy, but then I have to
write a helper like that for every facet I care about. (More casting than a
bass-fishing tournament. ;-) Just adding a few dozen helper functions in the
right places might be enough.

The doc isn't always a big help here, either. For example see http://xml.apache
.org/xerces2-j/javadocs/xerces2/index.html <http://xml.apache.org/xerces2-j
/javadocs/xerces2/index.html>

++++

Interface XSMultiValueFacet
...
getFacetKind

public short getFacetKind()

Returns:
The name of the facet: e.i. enumeration, or pattern.

----

LOL... OK, I've had days like that too, but could this get this fixed? Just
making it "Returns: a short indicating the facet type: i.e.
XSSimpleTypeDefinition.FACET_ENUMERATION or XSSimpleTypeDefinition.FACET
_PATTERN." would be helpful.

So, the big question: can we look for improvements in PSVI anytime soon?

Thanks,
Thomas Cox

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1170" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2><SPAN class=495123117-27082003>I have to use
org.apache.xerces.impl.xs.psvi.* pretty heavily in production software, and I
just wanted to post some musings and perhaps a wistful
question.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=495123117-27082003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=495123117-27082003>The PSVI APIs seem
to be fairly crufty. (Please don't take this as a rant. OK, maybe a
friendly rant... ;-) Of course, having spent far too much dealing
with the XML Schema spec, I have a great deal of sympathy for why that is
the case. I also understand it's in the "impl" set of packages, with limited
support, but it's the only game in town. (For me anyway - I don't know if it's
better or not, but I can't use <A
href="http://www.eclipse.org/xsd/">http://www.eclipse.org/xsd/</A> due to
licensing issues.)</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=495123117-27082003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=495123117-27082003>Here's my
"do-it-yourself" analogy:  Let's say I need a left-handed metric wing-nut.
I know I've probably got one in a Mason jar in the garage, so I put down my
tools, go out, dump the jar on my workbench, poke through it until I finally
find what I need, rake the parts back into the jar, and go back to
work.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=495123117-27082003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=495123117-27082003>That's
what PSVI feel like to me. It's especially poignant when I'm staring at
the
data I need in the debugger but it takes an extra hour to figure
out all the API hooks to look it up. It's not that big an issue if
you
only use it occasionally, but it's not so great for frequent use.
(Mind you, I'm VERY thankful I don't have to make a left-handed metric
wing-net from scratch. ;-) </SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=495123117-27082003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=495123117-27082003>Here's an example:
I'm traipsing through a schema, and want to find out if this element has an
associated enumeration. I've already looked up the type def, so I
call
-</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=495123117-27082003></SPAN></FONT> </DIV>
<DIV><FONT face="Courier New" size=2><SPAN
class=495123117-27082003>    static private ArrayList
getEnumFacet(XSTypeDefinition xstd)<BR>   
{<BR>        ArrayList enum =
null;<BR>        if (xstd != null &&
xstd instanceof
XSSimpleTypeDefinition)<BR>       
{<BR>           
XSSimpleTypeDefinition xsstd =
(XSSimpleTypeDefinition)xstd;<BR>       
    
XSObjectList xsol =
xsstd.getMultiValueFacets();<BR>       &nbsp
;   
if (xsol !=
null)<BR>           
{<BR>            
   
for (int f = 0; f < xsol.getLength();
++f)<BR>           &nbsp
;   
{<BR>            
       
XSObject xob =
xsol.item(f);<BR>          
         
if (xob instanceof
XSMultiValueFacet)<BR>         
          
{<BR>            
           
XSMultiValueFacet xsmvf =
(XSMultiValueFacet)xob;<BR>        
             
  
if (xsmvf.getFacetKind() ==
XSSimpleTypeDefinition.FACET_ENUMERATION)<BR>     
             
     
{<BR>            
             
  
enum = new
ArrayList();<BR>          
             
    
StringList vals =
xsmvf.getLexicalFacetValues();<BR>       
             
       
for (int v = 0; v < vals.getLength();
++v)<BR>           &nbsp
;             
  
{<BR>            
             
      
enum.add(vals.item(v));<BR>        
             
      
}<BR>            
           
}<BR>            
       
}<BR>            
   
}<BR>           
}<BR>       
}<BR>        return
enum;<BR>    }</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN
class=495123117-27082003></SPAN></FONT> </DIV>
<DIV><SPAN class=495123117-27082003><FONT face=Arial size=2>Well, OK; I got my
enumeration back, so I'm fairly happy, but then I have to write a helper like
that for every facet I care about. (More casting than a bass-fishing tournament
.
;-) Just adding a few dozen helper functions in the right places might be
enough.</FONT></SPAN></DIV>
<DIV><SPAN class=495123117-27082003><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=495123117-27082003><FONT face=Arial size=2>The doc isn't
always
a big help here, either. For example see </FONT><A
href="http://xml.apache.org/xerces2-j/javadocs/xerces2/index.html"><FONT
face=Arial color=#000000
size=2>http://xml.apache.org/xerces2-j/javadocs/xerces2/index.html</FONT></A><
/SPAN></DIV>
<DIV><FONT face="Courier New" size=2><SPAN
class=495123117-27082003></SPAN></FONT> </DIV>
<DIV><FONT face="Courier New" size=2><SPAN
class=495123117-27082003>++++</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=495123117-27082003><SPAN
class=495123117-27082003> 
<H3>Interface XSMultiValueFacet<BR>   ...<BR>getFacetKind</H3><PRE
>public short <B>getFacetKind</B>()</PRE>
<DL>
<DD>
<DL></DL></DD>
<DL>
<DT><B>Returns:</B>
<DD>The name of the facet: e.i. <CODE>enumeration</CODE>, or
<CODE>pattern</CODE>.</DD></DL>
<DD><FONT face=Arial color=#0000ff size=2><SPAN
class=495123117-27082003></SPAN></FONT> </DD></DL></SPAN></SPAN></FONT><
/DIV>
<DIV><FONT face="Courier New" size=2><SPAN
class=495123117-27082003>----</SPAN></FONT></DIV>
<DIV><FONT><SPAN class=495123117-27082003></SPAN></FONT><SPAN
class=495123117-27082003><FONT face=Arial size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=495123117-27082003><FONT face=Arial><FONT size=2><FONT>LOL...
OK, I've had days like that too, but could this get this fixed? Just making it
"Returns: a short indicating the facet type: i.e.
XSSimpleTypeDefinition.FACET_ENUMERATION or
XSSimpleTypeDefinition.FACET_PATTERN.</FONT>"  would be
helpful.</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=495123117-27082003><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=495123117-27082003><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=495123117-27082003><FONT face=Arial size=2>So,
the</FONT></SPAN><SPAN class=495123117-27082003><FONT face=Arial
size=2> big question: can we look for improvements in PSVI anytime
soon?</FONT></SPAN></DIV>
<DIV><SPAN class=495123117-27082003><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=495123117-27082003><FONT face=Arial
size=2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=495123117-27082003><FONT face=Arial size=2>Thomas
Cox</FONT></SPAN></DIV>
<DIV><SPAN class=495123117-27082003><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=495123117-27082003><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=495123117-27082003><FONT face=Arial
size=2></FONT> </DIV></SPAN></BODY></HTML>