OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] SAX for Binary Encodings (SAD-SAX)

[ Lists Home | Date Index | Thread Index ]

Simon St.Laurent wrote:

> I'm sorry, Alaric, but this is the classic story that's done so much to
> pollute XML and turn what was once a pleasant simplfication into an
> industrial-strength nightmare.  That it's frequently told by people who
> believe it doesn't do anything to help it.

Ok;

> I wish you could have been at the Extreme Markup Languages conference
> when Jeni Tennison gave a presentation on the impact of typing on XSLT
> and XPath 2.0.  As C. Sperberg-McQueen summarized it, "I was watching
> all these faces, all of them asking 'if Jeni Tennison can't deal with
> this, how am I ever going to?'"

I think that the difference in typing between XSLT/XPath 1 and 2 is more 
about the fact that they ripped out the old XPath type system (it had 
its integers and strings and booleans and stuff) to replace them with 
XML Schema-compatible ones, than just *adding* typing.

They didn't add stuff - they CHANGED stuff! So the old stuff isn't there 
any more!

Although one perspective no this could be that switching from XSLT 1 to 
XSLT 2 is like turning on an option - the programmer chooses to do so if 
they want to, otherwise sticks with XSLT 1.0 - but the unfornate fact 
that the difference is in a *version number* rather than an *option 
flag* is that everyone assumes that 2.0 must be inherently better than 
1.0 :-(

> 1) We don't all get to choose.  We don't all get to choose our tools,
> and even fewer of us get to choose the data we work with.  As these
> things spread across the landscape, they become unavoidable.  
 >
> All of the tools I write for processing XML now support namespaces.
> That isn't because I think namespaces are a good idea - in fact, I think
> they were the first sign that the people running XML had no clue what
> they were doing.  I support them because I have to, both to make my
> tools usable by others and because I have to deal with namespaced
> information.  I create it myself sometimes, a habit I got into when
> using other people's tools.

Ok. In order to see if this same pattern could cause problems with a 
typed extension to SAX, I'm going to try to map from the namespace 
issues into this.

Namespaces became everyone's problem because all the important XML 
vocabularies started using them extensively, right? And because of the 
transfer syntax of namespaces - with the prefixes - a processor that 
isn't namespace aware really can't make much sense of namespaced 
elements and attributes, since they have this random prefix shoved on 
them most of the time, and non namespace aware applications would be 
using literal string comparisions between element names and constants 
such as "first-name" to see what element was what. Namespaces still 
aren't a problem for applications dealing with XML vocabularies that 
don't use namespaces - just there are very few of those.

Part of the problem is down to the syntax used for namespaces; perhaps 
it would have been better if the Namespaces rec didn't introduce 
prefixes, but instead worked along the lines of:

1) Attributes don't get namespaces, only elements do
2) The attribute xml-namespace="URI" means that the containing element 
is in that namespace, and so are all its children unless another 
declaration states otherwise

That way, a non namespace aware application would still be able to rely 
on the first name element being called "first-name", making it more 
backwards compatible at the cost of greater verbosity due to repeating 
that namespace URI every time you switch namespaces (ugly in XSLT for 
example...).

This is clear in hindsight. I'm sure that if the Namespaces rec authors 
had thought about backwards compatability they would have come up with 
something similar, however. I presume, therefore, that they were not 
particularly worried about non-namespace aware applications, for one 
reason or another.

SO - learning from the mistakes made with Namespaces, what lessons can 
we take into account when doing a feasability study of a type-aware SAX?

"Really really think about what life will be like for people who don't 
want to use your optional extension, *even when they border with systems 
that DO*."

Now, since this is just an API extension, it will have zero effect on 
the interchanged bits on the wire, so we needn't worry about issues 
there. All we need to ensure is that applications that do not need the 
extension be totally free of needing to change if their SAX parser 
started providing the option. Luckily, the SAX people are smart - they 
use URIs in strings to identify extensions in a way that avoids these 
issues.

Is there a danger that, like with namespaces, lots of important XML 
vocabularies might start to depend on this SAX extension in such a way 
that applications are forced to use it to work with them? That's more of 
a potential issue, but the SAX extension just automatically handles 
something that you're already manuall doing anyway - parsing strings to 
get dates/integers/whatnot. You can still do it manually if you wish, 
meaning that the optional extension is not the only way to read in dates 
and so on - so it can't become a dependency if it's trivially removable. 
Lots of XML specifications already rely on *something* parsing integers, 
since they represent integers in decimal in XML!

Perhaps the biggest danger is that there might be a slow creeping wave 
of highly complex syntaxes used in XML content - like SVG path 
expressions, XPaths and so on - and that everyone gravitates towards 
writing parsers for these as part of typed SAX parsers. So after a 
while, to parse XPath, you have the choice of:

1) Use a typed SAX parser, which will return you an abstract syntax tree 
for the XPath expression - and thus indirectly forcing you to use the 
typed SAX parser for all of your document whether you like it or not!

2) Write your own XPath parser from scratch

Prevention of (1) is why I agree with the original poster's idea of 
having an option to the SAX engine to make it return *both* the original 
unmolested text *and* its attempt at parsing it. So you can just not use 
the parsing part (and ideally prevent it from wasting its parsing stuff 
you'll ignore in one of many ways) and keep accepting the plain 
characters for most of your application, while using the parsing part 
where you need it.

This is a strong argument FOR making this as an extension to SAX rather 
than a new API - if you had to switch to a totally new API for all of 
your XML reading to parse XPaths, changing bits of your code that really 
needn't change, that would suck!

> 2) Communicating expectations is harder than communicating data. Good
> documentation and schemas can provide more information, but there's a
> lot of experience behind "loosely coupled" vs. "tightly bound",
> especially where participants are widely distributed.

Yep - that's why I suggested the API handle the lack of type 
information, or the failure of type information to match what's in the 
document, by falling back to the existing SAX behaviour, in order to 
avoid this problem.

> 3) Bad ideas that start in one place frequently wander elsewhere.  W3C
> XML Schema is probably the classic example of this.  It's widely
> despised, even at conferences - like last summer's Applied XML show -
> where everyone claims to need that kind of tool.   Nonetheless, it
> continues to make life difficult for people from Word users to data
> binding implementers to XSLT developers.

Yeah :-(

The problem here, of course, is the original badness of the idea 
combined with the unforunate fact that it was proposed by a voice of 
authority.

However, good ideas from voices of authority ALSO tend to spread :-)

> I'm happy to see ASN.1 working to make itself more accessible to
> developers with different expectations, and I'm still happy to see ASN.1
> at work for people who actually want schema-first tightly-coupled
> development.  I'm not happy to see ASN.1-flavored proposals for
> revamping XML APIs because they don't fit ASN.1 expectations.  Building
> bridges between the two worlds is good, but there's definitely a limit. 

Think about the usefulness of typed SAX beyond ASN.1, however - typed 
SAX events could be generated from an XML document with reference to a 
schema in the schema language of your choice.

> XML has suffered enough here from types that you might want to pack up
> that circus wagon and find another freak show where it'll be more
> welcome.  Please don't tell that bogus story about types being a
> harmless option if you want me to take you seriously.

How has XML suffered from types? As I see it:

1) The official language for attaching types to XML sucks

2) This has had knock-on effects, such as the XPath/XSLT type system 
changing to align with XML Schema

But types in XML are *still* an optional add-on, in ways that namespaces 
aren't! You only *need* to write code that knows anything about XML 
schema languages if you're writing a schema validator or an XSLT 2.0 
engine, right? You can ignore references to schemas and xsi:type 
attributes to your heart's content, and your application that reads XML 
purchase orders and handles them will still be able to work, yes?

A non-type-aware application that encounters <numFingers 
xsi:type="integer">010</numFingers> (or, equivelantly, without the 
xsi:type and instead with a schemaLocation attribute pointing to a 
schema saying the same thing) will either:

1) If it has no hardcoded knowledge about the element, just ignore it or 
pass it through itself verbatim, as applicable - preserving the leading 
0, since it does not know of any interpretation rules concerning the 
element content, so MUST NOT ATTEMPT TO BE CLEVER.

2) Have hardcoded knowledge from the programmer (who had a copy of the 
specification for the vocabulary in front of them) that numFingers 
contains a positive decimal integer, and treat the content as the number 
ten; the xsi:type is just redundant extra information here.

3) Incorrectly (because it's broken) assume that the contents of 
numFingers is an integer written *backwards* with the least significant 
bit first, and remove the 'insignificant' zero at the end, and as such 
do something like output <numFingers xsi:type="integer">01</numFingers>.

Case (3) is the one that people who fear type-aware systems stripping 
their 'apparently redundant' information away and breaking things seem 
to fear. However, only the *obviously broken* code does this...

But getting back to the point - typed SAX.

Type-aware interpretation of XML is a fact of life as soon as you start 
passing anything other than human-language text in XML. As soon as you 
have something like version="1.0" lurking around, software is going to 
start doing things like converting that to a pair of integers and 
performing integer comparisons to see if this is a version it can support.

Typed schema languages (like XML Schema, not so much like DTDs) tend to 
set out a library of types, and a way of assigning those types to parts 
of an XML document, in an attempt to try and formalise this typing. 
Without such schema languages, we would instead say "The version 
attribute contains the version number", thus non-formally assigning a 
type. HTML is strongly typed; some attributes must have a valid URI in 
them, or an integer (width= and so on). This is not, in itself, a problem.

The problems seem to have arisen in the area of the schema languages.

But typed SAX - although it would DEPEND on some external schema 
language or something like xsi:type to get its type information in the 
first place - would not introduce any dependency on that source of type 
information into the application... and as I have visualised the 
interface, it would 'fail safe' in the absence of a schema by just 
reporting character data, thus not introducing a dependency on schemas 
or whatnot into the documents it processed.

So, I ask, what could go wrong? :-)

I might have missed something, some unforseen consequence... but I think 
the fundamental nature of this thing (doing something the programmer 
would do by hand automatically, but only if explicitly asked to do so, 
and giving up gracefully if it can't be done automatically) means that 
it can't possibly cause a problem.

ABS





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS