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] DOM Level 3, more or less flexible than AS?

[ Lists Home | Date Index | Thread Index ]

At 3:58 PM +0200 10/24/02, Eric van der Vlist wrote:

>If we go back to DOM AS, the idea (as I understand it) was to completely
>hide the schema system and rely on a query/request mechanism (the
>application would just have asked to the AS if such and such update
>could be done).

No, that's not really how abstract schemas worked (or at least it's 
not all they did.) They had a very detailed class hierarchy 
describing, for example, the allowable content model of an element. 
For example, here's what the ASElementDecl interface looked like in 

interface ASElementDecl : ASObject {
   readonly attribute ASDataType      type;
   readonly attribute unsigned short  contentType;
   readonly attribute boolean         strictMixedContent;
   readonly attribute ASContentModel  contentModel;
   readonly attribute boolean         isPCDataOnly;
   readonly attribute ASNamedObjectMap attributeDecls;
   ASAttributeDecl    getAttributeDecl(in DOMString name,
                                       in DOMString targetNamespace);

This also failed to fit Schematron. And this has all gone away now.

>IMO, this blackbox approach is the most generic API we can imagine and
>it could virtually cope with any kind of "schema" system, including
>Relax NG, Schematron or even one's own application.

That's what DOM Level 3 validation is about. It's just been split off 
into a more modular spec that was announced a couple of months ago. 
See http://www.w3.org/TR/DOM-Level-3-Val/validation.html

>By contrast, accepting the idea that an element or an attribute must
>have a "type" seems to be a step backward.

They are not required to. They are simply allowed to. Many elements 
and attributes will have null types. (The exact representation of an 
unknown type is still being discussed, but the working group clearly 
understands that they can't assign a type to everything.)

>Relax NG doesn't impose this (and doesn't guarantee to report type
>information consitently in all the cases) and Schematron has no
>"built-in" notion of type either.
>Furthermore, I don't see how you can implement rules like Schematron
>does so well with a type and a URI.

Typing is about annotation. Validation is about checking conformance 
to a schema. They are often confused, but they are not the same 
thing. I think the new batch of specs gets this a lot more right than 
the old ones did.  It's far more modular, and allows developers to 
pick and choose what they need without locking them in to any one 
schema language.

>I think that we are moving from a concept which could have been amended
>to support any type of schema and constraint to a concept which at the
>end of the day might be more complex and is narrow minded and very
>specific to the DTDs and W3C XML Schema approaches!

I suspect if you look more closely at the family of DOM 3 specs, 
you'll find that what you like is still there, and that a lot of 
things you'd find very ugly and obnoxious have gone away.

| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
|          XML in a  Nutshell, 2nd Edition (O'Reilly, 2002)          |
|              http://www.cafeconleche.org/books/xian2/              |
|  http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/  |
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |


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

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