- From: <bugzilla@wiggum.w3.org>
- Date: Sat, 20 Sep 2008 08:59:03 +0000
- To: www-xml-schema-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5732 Michael Kay <mike@saxonica.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mike@saxonica.com --- Comment #2 from Michael Kay <mike@saxonica.com> 2008-09-20 08:59:02 --- I think I would prefer an alternative approach. Firstly, I would prefer to see an XML syntax. Perhaps with some micro-syntax within the elements and attributes, but within an XML skeleton. I think there are many advantages of this in terms of making schemas readable and writable by software; it also means that we can use the same schema composition mechanism. Also, the experience with XQuery of designing a language that is both unambiguous and extensible is not one I would want to repeat. It should be possible to convert between compact syntax and full syntax using XSLT. Secondly, I would like to see an XML syntax that is essentially an abbreviated form of the current syntax, with all the abbreviations being optional: so users have full flexibility on how much "compact" and how much "verbose" syntax they use in the same schema document. One advantage of this approach is that users are never cut off from the full functionality of the language, while at the same time we don't have to guarantee that every possible construct has a compact form. I believe that it's possible using this approach to come up with a compact syntax that is a lot more usable than the current syntax while still being recognizably XSD. To take an example, here is an element declaration from the schema for XSLT 2.0: <xs:element name="analyze-string" substitutionGroup="xsl:instruction"> <xs:complexType> <xs:complexContent> <xs:extension base="xsl:element-only-versioned-element-type"> <xs:sequence> <xs:element ref="xsl:matching-substring" minOccurs="0"/> <xs:element ref="xsl:non-matching-substring" minOccurs="0"/> <xs:element ref="xsl:fallback" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="select" type="xsl:expression" use="required"/> <xs:attribute name="regex" type="xsl:avt" use="required"/> <xs:attribute name="flags" type="xsl:avt" default=""/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> I think this could be reduced to: <xs:element name="analyze-string" substitutionGroup="xsl:instruction" extends="xsl:element-only-versioned-element-type"> <xs:attribute name="select" type="xsl:expression"/> <xs:attribute name="regex" type="xsl:avt"/> <xs:attribute name="flags" type="xsl:avt" default=""/> <xs:element ref="xsl:matching-substring" occurs="?"/> <xs:element ref="xsl:non-matching-substring" occurs="?"/> <xs:element ref="xsl:fallback" occurs="*"/> </xs:element> I think this is a sufficient level of simplification. A key point is that this is not an alternative syntax, it is the result of applying a number of optional abbreviations: for example allowing xs:sequence to be omitted, xs:extension promoted as an attribute to a containing element, xs:complexContent to be omitted, xs:complexType to be omitted, attributes to appear before elements, etc. I would hope that we can apply these abbreviation rules systematically so that they are easily memorable for someone who knows (or, like me, half-remembers) the current syntax. Of course I haven't tried to work out the detail. I would like to do some things that are not mere syntactic sugar, such as allowing a restriction of a content model to be expressed in terms of the differences from the base type (as is currently allowed for attributes but not for elements). Michael Kay -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Saturday, 20 September 2008 08:59:36 UTC