[
Lists Home |
Date Index |
Thread Index
]
Robin Berjon wrote:
>
> 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?
Probably two. Say, XML and PER (I don't need to explain the reason, I
guess). However, encoding rules have been created over time (20+ years), so
now we have 3 main ones with minor variants. There are historical reasons
why we have each of them.
(ECN occupies a very special place in the X.69x series in that it is a
language for specifying encoding rules.)
>
> 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?
Would you say that the nature of XML Schema would change if a W3C BiM-alike
were introduced, to the point that XML Schema could no longer be
appropriately called an "XML schema language" and would need a name change?
Would XML Schema lose its ability to describe and constrain XML documents?
Something would change, I agree. One of the things that would change is the
way some people would look at the language (in some cases, schemas would be
used to always generate binary encodings rather than XML). Some people
would begin to consider XML Schema "syntax-agnostic" at that point. Others
would not.
Again, one could argue that this is the present, not just a possible future.
The BiM and other schema-based binary representations can be regarded -
using ASN.1 terminology - as "encodings of abstract data types defined in
XML Schema", XML 1.0 being another possible encoding. This concept may seem
strange to people used to think in terms of "syntax", but makes a lot of
sense to other people.
Alessandro
>
> > 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
>
>
|
