forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Noels" <stev...@outerthought.org>
Subject RE: draft howto dtd
Date Sat, 18 May 2002 20:12:39 GMT
Joerg wrote:

> You can do the same things a DTD can: describe what elements
> can be children to elements, and what attributes an element
> can have.
> The equivalent of
>   <!ELEMENT document (title,sect1+)>
> is
>   <xsd:element name="document">
>    <xsd:sequence>
>     <xsd:element name="title" type="title"/>
>     <xsd:element maxOccurs="unbounded" name="sect1" type="sect1"/>
>    </xsd:sequence>
>   </xsd:complexType>
>
> It's not all that horrible. And if you don't want to look at it,
> don't do it: write a style sheet to visualize the aspects you want.
> By the time you need it, chances are that some other lazy guy has
> already done this.

Of course, but this is only the simplest of examples. It's not the
syntax, the angle brackets nor the namespace prefixes that I have
troubles with. After all, we're used at using XML for various purposes
over here ;-)

Consider this:

<!ELEMENT foo (#PCDATA) >
<!ATTLIST foo bar CDATA #REQUIRED >

compared to:

<xsd:element name="foo">
  <xsd:complexType>
    <xsd:simpleContent>
      <xsd:extension base="xsd:string">
        <xsd:attribute name="bar" type="xsd:string" use="required"/>
      </xsd:extension>
    </xsd:simpleContent>
  </xsd:complexType>
</xsd:element>

and

<xsd:element name="foo">
  <xsd:complexType>
    <xsd:simpleContent>
      <xsd:extension base="xsd:string">
        <xsd:attribute name="bar" use="required"/>
      </xsd:extension>
    </xsd:simpleContent>
  </xsd:complexType>
</xsd:element>
<xsd:attribute name="bar" type="xsd:string"/>

The concept of local vs global declarations is clear to me, but adds
dramatically to the burden of doing XSLT on top of XML Schema. Add the
possibility of substition to that (not to mention extension/restriction
which are horribly implemented if you compare them with subclassing or
inheritance in OO languages), and the transformation problem becomes
even worse.

And these examples only touch the basic features of the XML Schema
language.

On a more tricky level (element content defaulting, gleaned from a post
by Jeni Tennison on xml-dev):

Wrong (and impossible to create using the graphical view of XMLSpy):

<xsd:element name="foo" default="default">
  <xsd:complexType mixed="true">
    <xsd:sequence>
      <xsd:element name="bar" type="xsd:string"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>

Right (impossible too, alas):

<xsd:element name="foo" default="default">
  <xsd:complexType mixed="true">
    <xsd:sequence>
      <xsd:element name="bar" type="xsd:string" minOccurs="0"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>

Find the difference :-)

> > and in many chances not transferable/equivalently
> > interpreted between different tools.
>
> On what observations do you base this statement? After all,
> I have no really good idea what else beside a schema driven
> editor and a validator is going to use the schema, and both
> use it for validation, which is pretty much nailed down, no
> room for interpretation there.

You live with the assumption standards are correctly implemented by
tools, regardless of their complexity. If a standard (or better: the
application of a standard) can only live within a certain predefined set
of tools, it isn't much worth as a standard.

My problem with XML Schema is that it offers too many possible ways of
declaring the same kind of thing, and believe me, when you hand over
such a language to a creative user, he will make use of the exotic
features, too. And then, you can only hope your editor, validation
engine et al. will implement the same kind of 'standard', which is
currently not the case.

</Steven>


Mime
View raw message