OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Validation vs performance - was Re: [xml-dev] Fasttext out

[ Lists Home | Date Index | Thread Index ]

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"
>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
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


swilliams@hpti.com http://www.hpti.com Per: sdw@lig.net http://sdw.st
Stephen D. Williams 703-724-0118W 703-995-0407Fax 20147-4622 AIM: sdw

fn:Stephen Williams


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS