+1 from me as well.With uP3 (I'm working on actually doing M5 today!) a lot of the custom XML config files have gone away in favor of Spring context XML which has nice schemas. I do agree that one task we should really look into is ensuring we have up to date DTDs or XSDs for all XML documents used in the framework.
-Eric Andrew Petro wrote:
+1 for the API un-changes Drew proposes. Drew,Having slept on it and on reflection, I support your proposal to restore the two-argument method behavior to non-validating, with appropriate JavaDoc to express what this method signature does and the missed opportunity of doing validation.It's the right correction to the uPortal APIs and I appreciate your proposing it and will appreciate your applying the change.However, broadly, eschewing schemas isn't the right direction for this project to be going in its use of XML.I've seen too many IT-staff-created errors in XML files that would have been prevented or easily identified with use of schemas and tooling that supports validation against schemas at author-time or at the least at usage-time. The change to resource loader to, um, scold loudly in the logs when validation fails, and to always try to validate, in an ideal would would have resulted in more use of schemas and more XML that successfully validates against schemas.> I don't think I have the bandwidth to create new schema just now.I get that. The modest change you propose is appropriate and is an improvement. It's a substantive shortcoming, however, not to go further and use schemas, and time for that needs to be built into time for XML work on uPortal, grumpily opined the man who also doesn't have time to get to this task.Andrew On Jan 10, 2008, at 8:54 AM, Drew Wills wrote:Andrew Petro wrote:How about we give the documents that are presently generating WARNings because they do not validate -- cannot be validated -- schemas so that they can be validated?Andrew,I see it this way: there's a 3-arg version of getResourceAsDocument() that allows clients to choose validating or non-validating. So at the end of the day you can use ResourceLoader to read any document with or without validation as your needs dictate.The question is what should happen with the 2-arg version... what should be the *default* behavior: validating or no?I'd say non-validating is a more natural default. I can't think of any general-purpose XML-parsing libraries that validate by default. DOM implementations, dom4j, etc -- you have to explicitly tell them to validate if you want it.And with ResourceLoader we're talking about a general-purpose utility. ResourceLoader doesn't have any intimate knowledge of any of the files it handles afaik.If you were browsing the methods of ResourceLoader in an IDE and you saw these 2 overloads:- getResourceAsDocument (Class requestingClass, String resource)- getResourceAsDocument (Class requestingClass, String resource, boolean validate)What would you guess would be the behavior of the 2-arg version? If I was guessing, I'd definitely expect non-validating.If we changed the 2-arg version so it doesn't validate, we could update the classes that invoke getResourceAsDocument() to call the 3-arg version and request validation where appropriate.I have time to do that. I don't think I have the bandwidth to create new schema just now.drew wills -- Andrew Wills UNICON, Inc. Office: (480) 558-2476 http://code.google.com/p/cernunnos/ --You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
smime.p7s
Description: S/MIME Cryptographic Signature
