[
Lists Home |
Date Index |
Thread Index
]
Bob Wyman wrote:
> 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...)
Ah, well, no offence but if I were to have fun inventing my own schema
languages (I don't plan to spend time on the one described above --
Mount Todo high enough already), I'd convert it to either RelaxNG, or
XML Schema, or Schematron (a likely target for the one above) depending
on my needs. I wouldn't shell out money for a toy project :)
> 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...
Ok, that's interesting, thanks for the input. Others have said they'd
pick BER, but I'd tend to agree that if you're going to have a binary
format it might just as well be the most efficient one.
> 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...
Yes, but given the breadth of applications in which XML is used, I think
there's room for two (XML and SomethingElse), without requiring the
fully extensive infrastructure it takes to support proper negotiation
and fallback. This was also discussed at the workshop, and one of the
requirements was that the first few bytes would tell you what you're
getting (typical magic number or similar). Given two, both of which are
set in stone and preferably both by the same body, then you need much
less of a framework for other options since you are actively excluding them.
But if that proves impossible, then yes, defining a framework might be a
good idea. If we can't get people to agree on a single binary format,
building what's needed to properly herd the cats would be a step
favouring interoperability.
>>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.
I agree, I don't think it's that bad. That is to say, there is
disagreement on some things, but nothing so bad that discussion can't
happen.
> 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.
Yup, it's likely worth it.
--
Robin Berjon <robin.berjon@expway.fr>
Research Scientist, Expway http://expway.com/
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
|
