cygri’s notes on web data

Hell froze over!

After 8 years of my nasty, crufty, hodge podged together HTML, last night we finally switched over to clean HTML 4.01 with a full complement of CSS. While there are a handful of bugs and some lesser used functionality isn’t quite done yet, the transition has gone very smoothly.

Good to see this happening. Slashdot is the epicenter of the geek world, and web standards advocates have complained about its sloppy tagsoup HTML coding for years. Ugly <font> tags everywhere, and we’re in 2005!

Besides increasing Slashdot’s nerd credibility, this will probably reduce their bandwith usage by a nice percentage, and user-made alternative stylesheets will surely start to crop up soon.

Read this. It’s priceless.

Look folks, I know that software rot (sometimes called “progress”) keeps growing, and backwards compatibility is not always possible. At one point I changed my TeX78 system to TeX82 and refused to support the older conventions. […] But in this case I see absolutely no reason why system people who are supposedly committed to helping the world’s users from all the various cultures are suddenly blasting me in the face and telling me that you no longer support things that every decent browser understands perfectly well.

(via Danny)

Meike Klettke, Uni Rostock: XML schema evolution and incremental validation (Slides, in German)

XML documents and document schemas change over time, that’s just a fact. Compare to SQL databases: Data is updated all the time, schema changes happen, columns are added to tables etc.

Update languages for XML are far from being standardized, and evolution of XML schemas hasn’t been considered much.

Especially schema changes are hard because there’s instance data that must be updated in order to be valid according to the new schema.

[skip over hard-to-summarize details]

(The simpler alternative pushed by vendors is schema versioning. Have multiple versions of schemas, validate against all (must match one), and downstream tools like XSLT scripts must be able to cope with multiple versions.)

Oracle’s XML component supports a limited form of schema evolution. MS SQL Server supports schema versioning.

Daniel Fötsch, Uni Leipzig: Operator hierarchy concept for XML transformation

Daniel reviews transformation methods for XML. You can do it on the plain text level with regular expressions etc, with APIs like DOM and SAX, with specialized languages like XSLT, STX, XUL and XUpdate. He talks about this last category.

The idea behind “operator hierarchies” is to create low-level transformation files automatically from high-level transformation files. You can write transformations on a higher level of abstraction, which makes the transformation file shorter and more readable and maintainable. Then it’s transformed through an “operator file”, and expanded into a low-level transformation file. In fact, you can have several levels of this operator expansion, starting with domain-specific operators, then generic operators, then low-level operators.

So you could have something like this:

   .(much XML)
   <isif condition="...">
       ... (XML) ...
   <iselse/>
       ... (XML) ...
   </isif>
   (more XML)

And this could be expanded to a much longer XSLT fragment.

Mostly it’s about avoiding repetition in XSLT files by factoring out common code.

Andreas Almer: Improving data quality in XML documents of desktop applications (Slides, in German)

Andreas works in a DaimlerChrysler lab. The problem: In specialised areas, like the automobile industry, XML documents are quite often directly exchanged between end users. Data quality then often suffers because there’s no strong validation in the chain.

He looks at different XML schema languages. DTDs are simple, but lack important features. XML Schema is powerful. Relax NG has a simple syntax and regular expressions, but the syntax leads to ugly deep nesting. Schematron is simple, but complex schemas are too much work. Examplotron is self-explaining, but cardinalities and datatypes are hard [?].

To help users, a simple, easy to learn, self-explaining and hand-writable schema language is needed.

He proceeds to introduce a new schema language. There are only two elements, <element> and <attribute>. Names, cardinalities, types etc are in attributes. There’s an assertion feature for simple rules. There’s comments for validation rules. Lots of examples in the last few slides.

[I think the validation rules are nice. They use XPath/XForms style expressions.]

Q: Why not get rid of the XML syntax to make hand writing easier? Because we live in a world of XML tools and so it’s good to have the schema in XML too. But it would be good for end users.

Thomas Müller: Passing XQuery sequence sections

Thomas talks about the roadmap of SQL with regard to XML support. (Slides, in German)

The current version of SQL (SQL 2003) has an XML datatype and some functions for converting between XML bits and relational data.

SQL 2007 will adapt the XQuery data model for the XML datatype and will allow embedding of XQueries into SQL (!).

SELECT C.Name, XMLQuery('$e//...' PASSING C.Procurement AS "e")
FROM Customer C
WHERE C.CustId > 2105

[The meat of the talk was over my head.]

Look at these Office 12 screenshots.

Microsoft imitates the Brushed Metal look of Mac OS X, just as Apple seems to be moving away from this look.

I just don’t understand why anybody would want their OS to look like a cheap ripoff of the previous version of someone else’s OS. Microsoft’s UI design team has no sense of taste fashion.

(via Signal vs. Noise)

Erik Wilde, ETH Zürich: Towards Conceptual Modeling for XML (Slides)

XML schemas don’t contain enough semantic information. Too much meaning is only present in the documentation. Erik wants a conceptual model for modeling with XML. Like the ER model in the database world, but better suited to XML — hierarchical and referential.

This becomes more important as XML moves from a pure data exchange format to an integral part of many applications. XML is moving from a library thing right into the core of programming languages.

No one can understand an XML schema just from looking at the source. A higher-level visual notation would be good.

Erik cites a paper from WWW2005 where the authors had collected lots of XML schemas from the web and analyzed them. Main findings: Either they were broken, or they didn’t use more than the basic DTD stuff. I believe it’s [this paper.]

There are two ways to relate entities in XML: hierarchical (nesting) and referential (using IDs).

He reviews the existing approaches. Most look similar to ER models with a few differences like relationsips going from attributes to entities (taking into account XML’s hierarchical structure). All have some limitations: target specific schema language, don’t support mixed content, weak formal foundations etc.

He wants to create a better model. It’s work in progress. He has worked out a list of requirements and is looking for feedback.