On Mon, 1 Apr 2002 11:00:36 -0800, Dennis Sosnoski <[EMAIL PROTECTED]> wrote:
>I haven't seen any public announcement on this, but it was covered in a >BOF session on Wednesday night and again in the main JAXB session >Thursday morning. The JavaOne site says slides will be posted this week. >Nothing is there yet, though. > >Joseph Fialli, the current Sun lead for JSR-031, stated that they'd >found the previous architecture to be too difficult to extend to support >Schema. He also said there'd been a number of requests they received >that couldn't be handled with the old architecture. I would like to set the record correct on a number of points since there appear to be several incorrect assumptions below. >The new approach looks a lot like Castor and the rest - the binding uses >JavaBeans or equivalents, the framework builds the beans (as opposed to >the objects building themselves in the current EA version), The new approach allows for either the old style implementation that embeds the framework in the object or for the framework to build the bean. The extra level of indirection at the user API level allows for both implementation strategies without forcing the implementation decision in the user api. Additionally, this architectural change allows for future support of binding existing JavaBean class(es) to a generated XML Schema. > validation >is handled in the setter methods of the beans. > They're also planning to >*require* SAX2 parser support, a really strange requirement; Actually, "require" is too strong a statement to make at this phase of the specification effort. This could be relaxed to an "optional" capability based on future feedback. > the current >EA uses a pull parser which has many benefits for data binding (I've got >an article on JavaWorld at >http://www.javaworld.com/javaworld/jw-03-2002/jw-0329-xmljava2.html? >covering SAX2 vs pull, if you're interested in the differences). Given the number of data binding runtime framework approaches that can be taken, we have stopped trying to define a single data binding runtime framework in the first version of the specification. Thus, we loosened JAXB EA requirement that its provided pull parser API must be implemented by a JAXB implementation. Additionally, if the user "wishes" to specify a specific SAX 2 parser, we provided a means for the user to specify one. However, the default implementation for unmarshalling can still be a pull parser, we just chose to not specify a pull parser API at this time. The rationale for not requiring a pull parser is there is no standard API for it. When the new streaming parser effort, JSR-173 (http://jcp.org/jsr/detail/173.jsp) is completed, JAXB will incorporate this standardized pull-parser API. For implementations that generate Java code to do a special-purpose, optimized unmarshaller, one can look at it as a binding compile time option to to either allow unmarshalling to be performed by a default mechansim (which can easily be pull parser) or by a specified standard SAX-2 parser. The rationale for allowing for SAX 2 parser to be specified is to allow the user to pick the quality of parse time validation they wish to receive (or not receive) as the case may be. > Some of >the existing JavaBean-based implementations are represented in the >expert group, so this may be a factor in the change of direction... The old architecture required ALL validation code be called from the generated object and one assumed that all validation code was generated in Java within that object. This is what was meant when the old architecture could not scale from DTD to XML Schema. It is quite a significant effort just to write an XML Schema validator nevermind the effort and to generate all that code. The new architecture enables one to generate all validation code in Java; however, it also allows for implementations to come up with shorter term solutions that do not require validation to be performed solely in Java code, i.e. streaming the Java content tree to an XML Schema validator. This change was vital to ensure that a JAXB implementation could be implemented in a finite amount of time while supporting a sufficient subset of XML Schema. -Joe Fialli, Sun Microsystems > >I suggested to Sun that they make the current code available as >unsupported open source. If you're using the current code and like the >results you might want to make the same suggestion on their JAXB >feedback list [EMAIL PROTECTED] If Sun doesn't want to let it >go perhaps an open source project to build an independent implementation >with the same sort of architecture would be good - email me directly as >[EMAIL PROTECTED] if you're interested in something of this sort. > >- Dennis > >Ying Su wrote: > >>Dear Dennis, >>I didn't find the news that Sun announced. Could you give me some explanations on >why it will be throwed? We are using JAXB currently. Thank you! >> >>regards >>Ying >>----- Original Message ----- >>From: "Dennis Sosnoski" <[EMAIL PROTECTED]> >>To: <[EMAIL PROTECTED]> >>Sent: Monday, April 01, 2002 2:08 PM >>Subject: Re: Seeking expert XMLer's opinion >> >> >>>Data binding is a good approach for this, but not JAXB. Sun announced at >>>JavaOne that the current JAXB EA is a deadend as far as they're >>>concerned - they're throwing it away and starting over with an approach >>>that looks a lot like the other data binding approaches already >>>available. It's a shame - JAXB has some really innovative features. >>> >>>Castor (http://www.castor.org) is probably a better approach to use for >>>now. The new JAXB won't even be out in EA form until late summer. >>> >>>- Dennis >>> >>>Ying Su wrote: >>> >>>>Hi, you can try Java XML Banding (JAXB) which can be found on Sun's Website. It's >faster than DOM and more powerful than SAX. >>>> >>>>regards >>>>Ying >>>>----- Original Message ----- >>>>From: "Bryan LaPlante" <[EMAIL PROTECTED]> >>>>To: <[EMAIL PROTECTED]> >>>>Sent: Monday, April 01, 2002 4:37 AM >>>>Subject: Seeking expert XMLer's opinion >>>> >>>> >>>>>I have a jsp custom tag that validates a submitted form. The tag builds an >>>>>object on both the server and client for handling required and grouped >>>>>element validation. The validate has a child tag that listens for an error >>>>>concerning it's assigned element and in the event that JavaScript has been >>>>>turned off it will output the error at the position of the page where it was >>>>>placed. Both tags support a wealth of options for grouping elements based on >>>>>conditions and validating against a regular expression. >>>>> >>>>>I would like to make it possible for the end user create an XML file that >>>>>would describe the form to be validated and save them all of the extra >>>>>typing into tag attributes. I have been reading through the >>>>>http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/xml/parsers/package-summ >>>>>ary.html and >>>>>http://java.sun.com/j2ee/sdk_1.3/techdocs/api/org/xml/sax/package-summary.ht >>>>>ml packages. I have not tried to use Java to read an xml file yet and some >>>>>advise about how to approach it would be appreciated. In a nut shell all I >>>>>want to do is read in the attributes for each element so that I can output >>>>>the client side object and build the server side object to validate the >>>>>elements of the form. >>>>> >>>>>Sorry so long winded. >>>>> >>>>>Thanks in advice. >>>>> >>>>>Bryan LaPlante >>>>>President >>>>>Network Web Applications Inc. >>>>> >>>>>=========================================================================== >>>>>To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". >>>>>For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". >>>>>Some relevant FAQs on JSP/Servlets can be found at: >>>>> >>>>>http://archives.java.sun.com/jsp-interest.html >>>>>http://java.sun.com/products/jsp/faq.html >>>>>http://www.esperanto.org.nz/jsp/jspfaq.jsp >>>>>http://www.jguru.com/faq/index.jsp >>>>>http://www.jspinsider.com >>>>> >>>>> >>>>��������������������������������������������������������Ӣ�칻 >�&��ǧu�s(S([h-+-����6�k�.Y"�(^(TM)��S(w%�עz(�^n++r��azg��� �� z(++�HDU,D� ��DD"��+r >�z�������r �z��j�����r0/00�j�!S(���ǫ�W��)�z����ms(T^�<�q��+�i���j�����r0/00��� >��l�ǫ�W���mz��--�<�q��+٥,""HDU �i� m���� �-� ��(>�s(z(楳��z����+٥ >>>> >>>___________________________________________________________________________ >>>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body >>>of the message "signoff SERVLET-INTEREST". >>> >>>Archives: http://archives.java.sun.com/archives/servlet-interest.html >>>Resources: http://java.sun.com/products/servlet/external-resources.html >>>LISTSERV Help: http://www.lsoft.com/manuals/user/user.html >>> >>> >>> >>��������������������������������������������������������Ӣ�칻 >�&��ǧu�s(S([h-+-����6�k�.Y"�(^(TM)��S(w%�עz(�^n++r��azg��� �� z(++�HDU,D� ��DD"��+r >�z�������r �z��j�����r0/00�j�!S(���ǫ�W��)�z����ms(T^�<�q��+�i���j�����r0/00��� >��l�ǫ�W���mz��--�<�q��+٥,""HDU �i� m���� �-� ��(>�s(z(楳��z����+٥ >> > >___________________________________________________________________________ >To unsubscribe, send email to [EMAIL PROTECTED] and include in the body >of the message "signoff SERVLET-INTEREST". > >Archives: http://archives.java.sun.com/archives/servlet-interest.html >Resources: http://java.sun.com/products/servlet/external-resources.html >LISTSERV Help: http://www.lsoft.com/manuals/user/user.html > ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
