Re: Validation vs performance - was Re: Fasttext out
Alessandro Triglia wrote: > ... > >ASN.1 folks call the data-description level "type definition" or "abstract >syntax", and call the on-the-wire representation "encoding" or "transfer >syntax". The main focus being on the "abstract syntax" enables multiple >distinct "encoding rules" to exist, each specifying a different on-the-wire >representation of the data that has been defined at the "abstract syntax" >level. > >... > >I am not saying that the ASN.1 solution fits all cases (or even most of the >cases). I know that many people prefer thinking in terms of >bits-on-the-wire (or in terms of Unicode characters to be encoded in some >character-encoding before being placed on the wire), and I am not >questioning their views here. > >However, I suspect that many applications are being built around a schema >(now often XML Schema) in such a way that they will not tolerate any >variations to the form of XML document that does not conform to the schema. > > I mentioned XML consisting of idioms along with syntax and other explicit standards. One powerful idiom that has become accepted and expected with XML is that, whenever at all possible, you produce precisely but accept loosely. This is a direct expansion of the IETF meta-rule that states a similar principle. Furthermore, when accepting loosely and re-emitting an existing document/object, you attempt to preserve anything originally present, even if you didn't expect it. For instance, an 'object', i.e. a complex data type, may have grown a new field. You should not die when encountering this field and if you are modifying and exporting that object, you should preserve the field. This is a very powerful way to support schema evolution, router or separation of concerns patterns, and many other cases where you do not have a fixed or completely shared schema/IDL. It is for these and other reasons that IDL-based development, fixed schemas, and native-language object representation of what could be called "network business objects" is suboptimal in terms of development and maintenance requirements. If it can be further proved to be suboptimal in terms of processing efficiency, one of my goals, a paradigm shift is in order. >... > >Does it make any sense to compare ASN.1 with XML Schema? Probably yes. > > The evolution of thinking that led to ASN.1 and later to XML Schema et al is very interesting, but it's not that helpful to deconstruct it all. ASN.1 is, of course, a logical data/API definition syntax, normally compiled into code and data structures. (It should have an interpretable meta-data representation and an interpreter, but this wasn't a popular traditional mode as far as I could tell.) XML Schema is interpretable validation metadata. It was always meant to be loaded and used at runtime, whether by a more native-representation style application or one that was more interpretive. You can think of it as some degree of interpreted centralized data dictionary business rule enforcement that helps applications avoid embedding as much of that in application code. (Many using that model would like some extensible way to complete the idea; I've designed an XML template-based approach that allows arbitrary Java/Jython/etc. code to be invoked.) This kind of power is apparent in best practices like GUIs that are built using nothing but the Schema, a path, and a field type identifier where each field is validated against the Schema to avoid embedded validation code, which is something we did in a project over 18 months ago. This fits new XML-driven GUIs very well. This represents evolution/revolution on multiple levels. Is it something magic about XML Schema vs. ASN.1 syntax or expressibility? Nothing that couldn't have been tweaked. It was an evolution of idioms, assumptions, packaging, expectations, etc. This is nearly the same situation with Java, and putatively .NET, compared to C++ and older languages/environments/idiom paradigms: Many of the cool things with Java could have been done before, but it took a fresh playing field with high initial expectations, stated idioms, goals, and finally popularized best practices to raise the paradigm bar significantly. New bridges between ASN.1/xER and XML are somewhat interesting, but if they only address a fraction of the expected idioms, I remain uninterested. Additionally, I am not sure that they are necessary or useful beyond a few cases. >XML Schema has a dualism between value and lexical representation, which is >not very far from the ASN.1 dualism between value and encoding. The main >differences are: > >1) In XML Schema, the concept of value only exists for simple types, whereas >in ASN.1, the concept of value exists both for complex types and for simple >types. > > Any 'subtree' in an XML Schema is equivalent to a 'complex type'. Same structure, same thing. I posit that there are many instances where you want a partial schema or no schema at all. >2) XML Schema specifies one standard mapping between the value space and the >lexical representation, whereas ASN.1 specifies multiple standard mappings >(encoding rules). > >... >Alessandro Triglia >OSS Nokalva > > > sdw -- swilliams@h... http://www.hpti.com Per: sdw@l... http://sdw.st Stephen D. Williams 703-724-0118W 703-995-0407Fax 20147-4622 AIM: sdw
begin:vcard fn:Stephen Williams n:Williams;Stephen email;internet:sdw@l... tel;work:703-724-0118 tel;fax:703-995-0407 tel;pager:sdwpage@l... tel;home:703-729-5405 tel;cell:703-371-9362 x-mozilla-html:TRUE version:2.1 end:vcard
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format