Subject: Re: [docbook] RFE #1998852: Provide a mechanism to group parameters.
Norman Walsh wrote: > The DocBook TC is considering solutions to RFC 1998852 which asks > for a mechanism to group method parameters. > > Instead of creating new elements for this purpose, it was suggested > that we already have a group element that we could use for this > purpose. (It already serves an analagous role in grouping arguments in > a cmdsynopsis.) > > The results can be seen in this experimental customization layer: > > And its accompanying test document: > </article> > > This seems a perfectly tractable answer, but its worth noting that > this would be the first case of an element with two distinct, > unrelated content models. (We already use multiple patterns for the > same element to handle validation of some attribute co-constraints, > but those are much more closely related, or at least they feel that > way to me.) > > Does anyone think that this would be confusing? > > Technically, there is no way to represent this in DTD syntax and, > though it could be represented in XSD, our current method of > generating the XSD would not be able to cope. But I'm inclined to > think that we shouldn't feel constrained by the limitations of DTDs > and perhaps we need to build a better XSD in any event. rng wise looks good. I don't feel any antipathy towards overloading the group element. Common purpose even if a different 'place' in the schema. Am I right in thinking that so far, we've been OK with 'backwards' translation to both DTD and xsd? I'm a little more than 50% supportive of retaining that ability, sensing that people happily quote that docbook works with XSD. I shan't shout if you go with this solution, just a little concerned that some users (those locked into W3C/MS worlds) who are xsd bound might hurt if this breaks that assumption? "perhaps we need to build a better XSD in any event" Does that mean something other than Jing to go from .rng to .xsd? regards regards -- Dave Pawson XSLT XSL-FO FAQ. http://www.dpawson.co.uk