[
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"
>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@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
begin:vcard
fn:Stephen Williams
n:Williams;Stephen
email;internet:sdw@lig.net
tel;work:703-724-0118
tel;fax:703-995-0407
tel;pager:sdwpage@lig.net
tel;home:703-729-5405
tel;cell:703-371-9362
x-mozilla-html:TRUE
version:2.1
end:vcard
|
