[rfc-i] RFC editing tools
stefan at aaa-sec.com
Wed Dec 12 18:29:42 PST 2012
On 12/12/12 10:43 AM, "Martin J. Dürst" <duerst at it.aoyama.ac.jp> wrote:
>On 2012/12/12 0:45, Stefan Santesson wrote:
>> One more thing that we may want to consider if choosing an XML schema as
>> the source format.
>> Curent xml2rfc defines elements using compolex types with mixed content.
>> That is, using elements where you freely can mix text and subelements.
>> That is probably a good solution to make the XML Schema manual-edit
>> friendly, but it makes it a great deal harder to parse the content
>> At least with the tools I'm familiar with.
>> I imagine that it would be possible to convert an XML document according
>> to the xml2rfc schema to an XML schema that isn't using mixed content.
>> This might be a consideration for a source format where you could add
>> to an xml2rfc doc to capture some of the data currently missing for
>> allowing transformation to all presentations formats, including back to
>> xml2rfc if necessary.
>This doesn't make sense to me. Mixed content is what you need for
>running text. So the markup that describes paragraphs in xml2rfc uses
>mixed content. It is possible (as Julian said) to wrap every bit of text
>in an element, but it would be hopeless overkill.
>On the other hand, mixed content isn't in general very appropriate for
>simple data, including metadata. But I'm not aware of places where
>xml2rfc uses mixed content needlessly. If you know some of these, please
It depends on for what purpose you define the schema.
If it is for human readability and for being human edit friendly, mixed
content is necessary.
At least the tools I use for programatic XML parsing and creation, is more
suited for content that is not mixed.
The thought behind the comment was that it may not be necessary to have a
canonical source format that is human edit friendly, but rather suited for
programatic creation and parsing.
As long as it can be converted to an edit format (such as xml2rfc),
possibly with loss of some formatting metadata, and to any display format.
It may be valuable if that allows everything to be captured in a clean and
That of course would require the RFC editor to have an editing tool that
would allow the final formatting instructions to be added to the canonical
source format using any allowed editing format as input.
But maybe I'm just plain wrong.
More information about the rfc-interest