>A notable feature of XML Schema and RELAX NG is that the syntax of
>the schema languages they define is also XML, whereas the syntax
>of ASN.1 specifications is unique. It does not correspond to a
>transfer syntax generated by any of the encoding rules. However there
>is an IETF draft of a specification for representing ASN.1
specifications
>in XML syntax called ASN.1 Schema. That specification brings to ASN.1
>all the advantages attributed to XML Schema and RELAX NG in having an
>XML syntax.
I agree with Steven Leggs thorough answer to Chris Serberinos "nagging
ASN.1 beginner questions".
Its just the above few lines I wish to comment.
With XML came the XML browsers. XMetal was one I tried. Microsoft has
one.
Its smart that a message can be folded and unfolded so the user can
concentrate
on whichever level he/she wishes to inspect the given XML - is it
string or
message or something else ?
However:
The purpose of folding/unfolding the protocol spec. ie. the
specification
of the message is not clear to me.
And yet:
I prefer to think of a message specification as the start of the type
definitions in a computer program.
If a message set was to be defined in say Pascal or C one would start
from
"the leaves" , then one would specify the "minor twigs", then "major
twigs",
then "the branches" and finally "the stem".
In order to understand what is going on when first reading a message
specification it is very convenient that ASN.1 starts "bottom up" with
defining the stem, then the branches and so on.
Many tricks can be thought of to ease the understanding of the whole
tree
structure. "Hypertext-style" comes to my mind:
Message-set ::= CHOICE
{
mess1 Mess1,
mess2 Mess2
...
}
so you click on mess1 and you are brought to its definition.
When the whole tree is described as a series of definitions the reader
has to
jump around in order to find his own meaning. I guess an ideal case
for intro-
duction of a "hypertext" solution.
I have come to the conclusion that the message specification is
something
completely aside the set of messages. Its read in a different way. It
is
written for a different purpose.
I think it is a mistake to describe it in XML. XML - like the transfer
syntaxes of the ASN.1 environment - BER, DER, PER, XER and so on - are
linear in their nature.
It occurs to me that there could be some idea in trying to describe
e.g.
BER in XML - or even PER that I never learned properly.
The effect would be that one could take a bulky message "from the
line"
that needed to be debugged or inspected for some reason, take it into
an XML browser that was - say PER enabled. If the browser knows PER it
would know how to fold and unfold leaves, twigs and branches of the
PER message.
Maybe this exists as a tool already ?
Steen Oluf Karlsen
Søholtvej 6
Vester Vandet
DK-7700 Thisted
Danmark
Tel +45 97 97 72 72
email [EMAIL PROTECTED]
