[
Lists Home |
Date Index |
Thread Index
]
Alessandro Triglia wrote:
> Robin Berjon wrote:
>>You're missing the point, the operative word being "universality". An
>>XML parser can successfully read anything produced based on an XML
>>schema language (not to mention all that can be done without
>>any schema)
>
> How does this prevent the use of ASN.1 for specifying schemas?
When did I say that something should prevent one from using ASN.1 as an
XML schema language? Only recently I was joking with a friend about
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. However that's not at all what I'm
interested in within this thread.
What I'm trying to get at is that we have an interesting discrepancy of
users and principles here, and that it ought to be explored.
On one side we have a sizeable chunk of people that think (and often
strongly so) that having a single concrete syntax with minimal
optionality is a very important asset.
On the other side we have a group of people that appear to think that so
long as you have an abstraction cleanly defined, you'll get
interoperability no matter how many concrete syntaxes you may have to
deal with.
Since I've been an XML-head for quite a long time, I have little trouble
seeing the value in the first side. However it's been cracking at the
seams a little here and there, notably with the discussions on
subsetting, and of course much of my job consists in having problems
thrown at my face where XML doesn't quite cut it (which is refreshing ;).
I'm interested in "experience feedback" from the second group, of which
you are. 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? 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?
This touches on many permathreads and/or architectural issues (schema
languages, binary infosets, subsetting, concrete syntax vs data model,
etc). Without a conscious effort to understand the issues that "having
many options" has, and of why those issues are expressed, this
particular intersection of permathreads could go on forever, but it
won't be very interesting :)
I don't know what your impression was but I found the workshop brought
forth considerations clearer than "just say no" vs "if you just do that
it'll work". I was hoping to bring a little of that over here.
>>-- unless that schema language is ASN.1 (which could be an
>>argument for
>>saying it isn't exactly an XML schema language).
>
> The various existing proposals to introduce a schema-dependent alternative
> binary representation for XML (similar to the BiM) go in the opposite
> direction to what you are saying here. Will XML Schema cease to be a true
> "XML schema language" as soon as (and if) the W3C standardizes a
> schema-dependent alternative binary representation for XML (assuming they do
> so)? Certainly not.
Would you care to expose why you are so certain?
> One could argue that we already have this situation today, due to the
> existence of the BiM
Yes, but I'm talking about mindsets not technical possibilities. I could
use XML Schema to generate music if I wanted to, but that wouldn't
change the fact that right now, it pretty much is a schema language for XML.
>>If all you have is an ASN.1 schema, and you're on the receiving side,
>>you don't know what you're going to get.
>
> The same is true for the BiM or whatever binary alternative the W3C will
> possibly create. You don't know what you are going to get.
Yes, and that's an issue that needs careful consideration.
>>If it's an ER you don't know
>>about you won't read it. That just won't happen if you're
>>using XML. You
>>can chose to consider this unimportant, but a lot of us XML
>>folks think
>>it is a core asset.
>
> So people should just drop the idea of introducing a binary alternative?
Of course not, especially as people won't stop doing so with wishful
thinking. But we're treading on brittle ground. The question at this
point in time is not so much whether there are technical solutions to
binarisation problems since those can be found twelve a penny out there
(granted, with varying quality). It's about how it fits into a much
larger system, at what cost, with what trade-offs.
--
Robin Berjon <robin.berjon@expway.fr>
Research Scientist, Expway http://expway.com/
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
|
