- From: Jeff Rafter <lists@jeffrafter.com>
- Date: Thu, 04 Aug 2005 09:53:00 -0700
- To: noah_mendelsohn@us.ibm.com
- CC: Michael Kay <mike@saxonica.com>, 'Pete Cordell' <petexmldev@tech-know-ware.com>, xmlschema-dev@w3.org
> I'm not worried so much about the implementers as the users. XML Schema > is no more complex to implement well than languages like, say, Java. Would > you feel good if JavaSoft promoted a checklist so that vendors could say, > I don't support: > > _ for loops > _ interfaces > _ casts > _ protected Okay, this is the second or third straw-man thrown out in this thread. No one is saying that we expect a feature list that allows someone to not implement element declarations or something else so intricately required (though this might be an excellent feature on the list in the case of bare-bones datatype implementations-- in such a case who needs elements when all you are defining are data types?) Yes, no one would have an XML Parser that didn't support elements or attributes-- but there are a fair number of non-essential features in XML that people don't support e.g. DTDs (in the case of SOAP), Validation, external resolution, detection of malformed entities in declarations where the entity is not referenced-- and there is no one walking around with sandwich boards touting the end of the world is nigh. AElfred for example can be used in non-validating mode and still detect functional DTD problems... this is a feature that other parsers do not have. I am not coming out fully in favor of building a feature list-- there are just items that implementers don't want/need to build out in many situations-- turning our nose up in the air and saying that they are just not conforming or complete is not a very inclusive strategy. If someone builds a databinding tool I don't care if they implement the key/keyref system. All the best, Jeff Rafter
Received on Thursday, 4 August 2005 16:53:15 UTC