Cart
[Home] [By Thread] [By Date] [Recent Entries]
> > 1. What about Schemas is hard? To me, it boils down to whether they're conceptually hard or syntactically hard. If it's the later, then tools will mask the syntax difficulties. It seems the WG went beyond well-formedness and strived to remove any implicit assumptions, for example: <element name="foo"> <complexType> <sequence> <element name="bar" type="string"/> <element name="baz" type="integer"/> </sequence> <attribute name="qux" type="decimal"/> </complexType> </element> Now, couldn't this have been simple stated as: <element name="foo"> <element name="bar" type="string"/> <element name="baz" type="integer"/> <attribute name="qux" type="decimal"/> </element> where there's an implicit complexType and sequence? I'm sure this would not appeal to a lot of people, so especially those driven nuts by the ambiguities of HTML, but it sure would have made the syntax less verbose. But it really doesn't matter, much, IMHO. Tools will cover this annoying verbosity in any case. The parser will be simpler which is probably more important. If Schemas are conceptually hard, that's a different matter. certainly the rules for namespaces, <all> model groups, and seemingly odd inheritance restrictions certainly are difficult to master. Here, tools may help by enforcing these rules through edit controls and choice presentation, but that's not sufficient for understanding by the schema author. To understand, he needs not only to know the spec (which is no easy task), but the decisions and compromises that were made in the writing of the Recommendation. This is where XSDL will stand or fall, on the conceptual complexities, not the syntactical ones. And I don't think those concepts and their motivations are forthcoming in an easily digestible way for Schema authors. You'd have to be a WG member who took good notes to do this, and you have to speak plain. Not easy for most experts.
|
