[
Lists Home |
Date Index |
Thread Index
]
Robin Berjon wrote:
> making a simple Schematron-alike based on assertions stated
> using CSS syntax and selectors :) The more ways people have
> that suit their needs to constrain their XML, the better.
A really interesting way to do a new "schema" language would
be to write a simple translator that converts it to ASN.1. Then, you'd
have your little language (suiting whatever need you might have) but
you'd also have XML, DER, PER, etc. encoding support for free. (well,
maybe you'd have to pay money, but you wouldn't have to write much
code...)
> If you were given the power to go back in time and be Supreme
> God of All ASN.1, how many ERs would you need, which would
> they be, and why?
Two. Textual and Binary. (XML and PER) The textual would be
like XML and include a large number of variants to handle character
sets while the binary would be PER. I would also provide profiles for
both encodings so that you could produce distinguished forms that
could be signed. That's all...
However, in the computer world, we are often faced with the
reality of some pretty strange mathematical systems. You see, it seems
that while in school they teach you that you can count like this:
0,1,2,3,4,5,6, etc. up to infinity. The reality is that when you're
building interoperable systems, the number system looks like this:
0, 1, many.
i.e. if you support more than one then you've probably done
the work to support any number greater than one. And, you had better
make sure you can support more than two since the moment there are
two, someone is going to argue for three, then four, etc...
For me, the key missing element in the XML world is a compact,
binary encoding that can be easily written and read. I've got other
issues, but they are substantially less important to me than getting a
compact binary encoding.
>we have an interesting discrepancy of users and principles
> here, and that it ought to be explored.
Actually, I think the differences are fewer than you may
think. Back when this debate got started, the SGML and ASN.1 camps
agreed completely on the value of generic encoding, etc. However, one
group was focused on document processing and the other was focused on
networking. This was back in the day when we didn't have many WYSIWG
editors and worked on character cell terminals not bitmapped displays.
People built documents by editing markup by hand. (runoff, nroff, tex,
scribe, etc.) On the other hand, the network folk were dealing with
really low bandwidth communications ("high speed" 1200 baud modems!)
and would spend days figuring out how to squeeze a few bits out of a
packet...
What should have happened back then is what could happen
today... Now that you can map freely from XSD to ASN.1 and from XER to
DER to PER, we can finally make both groups happy with a single
solution. The document folk and the ones who can afford the luxury of
textual formats can have them. The bit-twiddlers can have what they
want and we can all agree on the value of self-describing data
structures, generic encoding, etc. We should have done this 20 years
ago... We should have found a compromise instead of fighting it out
and thinking that "winner takes all". But, we've all learned a lot in
the last twenty years so maybe we shouldn't be so harsh on our old
selves... Let's do what we should have done and put this issue to
rest.
> Surely, there must have been some concerns about having so
> many ERs, about the overhead of negotiation, about cases
> in which it couldn't happen, about cases in which it
> failed, etc, no?
Sure I'm concerned. However, I'm also convinced that we have
no choice but to deal with these issues. We need both textual and
binary encodings. Given that we need two, we'll need to deal with most
of the issues that relate to "many". (see my notes above concerning
0,1,many...) We should stop arguing about having two and focus our
efforts on trying to keep "many" as small as possible.
bob wyman
|
