[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Entities (was Re: XSchema Spec, Sections 2.0 and 2.1 (Draft 1))
John Cowan wrote: > That doesn't mean that I wouldn't be interested in defining an > XML-level mechanism for XSchema piece reuse using element/attribute > machinery. The main question there is just what should be reusable. > To my mind, the obvious choices are content models or parts thereof, > and attributes or groups thereof. Do you see anything else that > could usefully be reused? Hi! I've been working on an XSchema-like (by concept) solution for a couple of weeks. My first intent was to do "literate programming" for our DTDs i.e integrate documentation into the DTDs. I ended up with something that looks very similar to your XSchema proposal with additional markup for documentation (which has also been discussed on this list). Having the power of managing my own framework for specification structures (which is a weakness too, naturally) I thought that I just as well could remove or rather replace the parameter entity machinery (which I dislike). My short analysis gave the following desired characteristics that I used parameter entities for earlier: * Modularity * Parameterisation * Reuse I implemented those with with the follwing constructs * Inheritance of type, an "IsA" relation * Inheritance of structure * Use of structure by reference Apart from the constructs you mention I also find it usful to parameterise enumeration values in attribute declarations. IMO parameter entities (or general entities in XSchema instances) are not good candidates for this. They work on a syntactic level rather than on a structural level and more important, they are imperative or explicit in contrast to declarative. This makes them hard to use and maintain (e.g you must know what will get expanded when and by whom). Instead I think it is of greatest importance that native constructs for basic inheritance and parameterisation are included XSchema. Since simplicity is a motto I think parameter entities (and alike) must go away. They might be somewhat simpler to implement and understand (as a concept) since they are more primitive, but in practice, the resulting schemas will be far more complex and hairy compared to a declarative solution. To be more concrete, the example below outlines my current implementation. I expect to make the results of this public as a case study on our website when it is complete. Currently I use DSSSL in Jade to convert the schemas into DTDs (and the code is fairly simple). Cheers, </David> ----------------------------------------------------------------------- David.Rosenborg@x... Stockholm Stock Exchange Example: My schema have a section <fragments> which can hold definitions of parts of content models and attribute lists. The interesting parts are the "implements" attribute and the base/extends construct. First some common elements and constructs <document-type name="common"> <title>Common Elements</title> ... <fragments> <abstract-type name="chapter-content"/> <abstract-type name="emphasis"/> <mixed id="text"> <element name="emphasis"/> </mixed> </fragments> <element-declaration> <name>chapter</name> <content-model> <sequence> <element name="title"/> <element name="chapter-content" occurence="zero-or-more"/> <element name="chapter" occurence="zero-or-more"/> </sequence> </content-model> </element-declaration> <element-declaration implements="chapter-content"> <name>p</name> <content-model> <cm-ref linkend="text"/> </content-model> </element-declaration> ... </document-type> The following is a simple document schema. <document-type name="vanilla"> <title>Simple Document</title> <!-- Inherits the common element set --> <base> <extends name="common"/> </base> <element-declaration> <name>vanilla-document</name> <content-model> <sequence> <element name="title"/> <element name="chapter" occurence="one-or-more"/> </sequence> </content-model> </element-declaration> <element-declaration implements="chapter-content"> <name>note</name> <content-model> <!-- Extends a mixed contend model --> <mixed> <base> <extends name="text"/> </base> <element name="some-extra-element"/> </mixed> </content-model> </element-declaration> <element-declaration implements="emphasis"> <name>strong</name> <content-model> <pcdata/> </content-model> </element-declaration> ... </document-type> The DTD generated for vanilla-doc: <!ELEMENT vanilla-doc (title, chapter+)> <!ELEMENT chapter (title, (p | note)*, chapter*)> <!ELEMENT p (#PCDATA | strong)*> <!ELEMENT note (#PCDATA | strong | some-extra-element)*> <!ELEMENT strong (#PCDATA)> ... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|