headers
Aamer Akhter (aakhter | 7 Mar 2011 09:15
Picon
Favicon

XMLmind validation error: sequence of child elements is incorrect

Hi folks,

I'm working on xml2rfc with xmlmind. There is a validation feature
(Tools->Check Validity)  that is reporting the below error:

" the sequence of child elements is incorrect [cvc-complex-type.2.4]"

The error is on the <reference /> stanza. Any ideas what is wrong with
the below?

    <references title="Normative References">
      <?rfc include="reference.RFC.5101" ?>
      <reference anchor="iana-ipfix-assignments">
        <front>
          <title>IP Flow Information Export Information Elements
(http://www.iana.org/assignments/ipfix/ipfix.xml)</title>
          <author surname="Internet Assigned Numbers Authority" />
        </front>
      </reference>
    </references>
Permalink | Reply | 1 comment |
headers
Julian Reschke | 7 Mar 2011 09:27
Picon
Picon

Re: XMLmind validation error: sequence of child elements is incorrect

On 07.03.2011 09:15, Aamer Akhter (aakhter) wrote:
> Hi folks,
>
> I'm working on xml2rfc with xmlmind. There is a validation feature
> (Tools->Check Validity)  that is reporting the below error:
>
> " the sequence of child elements is incorrect [cvc-complex-type.2.4]"
>
> The error is on the<reference />  stanza. Any ideas what is wrong with
> the below?
>
>      <references title="Normative References">
>        <?rfc include="reference.RFC.5101" ?>
>        <reference anchor="iana-ipfix-assignments">
>          <front>
>            <title>IP Flow Information Export Information Elements
> (http://www.iana.org/assignments/ipfix/ipfix.xml)</title>
>            <author surname="Internet Assigned Numbers Authority" />
>          </front>
>        </reference>
>      </references>

The DTD says:

<!ELEMENT front       (title,author+,date,area*,workgroup*,keyword*,
                        abstract?,note*)>

so it's probably caused by the missing <date> element (yes, that 
shouldn't be required in the first place).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel M. Halpern | 7 Mar 2011 19:06

Dating problem

I have noticed that idnits and the draft submission tool appear to 
differ on the acceptable form of dates.
IDNits is perfectly willing to accept month and year.
However, the submission tool has recently (at least) been refusing to 
accepts submissions, complaining about invalid date.  If I add day, the 
problem goes away.

Yours,
Joel
Permalink | Reply | 0 comments |
headers
Carsten Bormann | 8 Mar 2011 12:52
Favicon
Gravatar

tools.ietf.org/wg/core cycling through inconsistent states

It appears that some of the results when you randomly access the above page are in a different state from the others.
E.g., on one of them draft-ietf-core-coap is not a WG document (but it does have some recent drafts!).
Don't have more precise data yet.

Gruesse, Carsten
Permalink | Reply | 1 comment |
headers
Alice Hagens | 9 Mar 2011 00:28

page breaking - Re: xml2rfc community comments

The RFC Production Center agrees with the following 2 comments regarding page breaking in the text output
of xml2rfc.

Christopher Dearlove wrote:
> ... regarding page control issues. Currently tables can
> be split (badly) and captions of tables and figures put on
> separate pages to their table or figure. Less critical, but
> while I'm on a wish list, I don't like section headings at
> the foot of a page while the section starts on the next page.

Similarly, John Klensin wrote:
> better handling of widows and orphans 
> (especially with regard to section title-text and lists with 
> undented headings top my personal list,

Julian Reschke wrote:
> From the practical point of view: I'd simply not worry about where page breaks end up in internet drafts.
Let the RFC production center deal with it when the time is ripe.

Currently, the RPC deals with it by converting XML to nroff, then handling page breaks using commands in the
nroff.  Historically, the RFC Editor has been encouraged to switch to XML entirely, i.e., abandon the
intermediary nroff step; this would be more feasible if the handling of page-breaking were improved.

Perhaps the RFP could include improved placement of page breaks.

Thanks,
Alice
for the RFC Production Center
Permalink | Reply | 7 comments |
headers
Mark Nottingham | 9 Mar 2011 09:00
Favicon
Gravatar

Draft formats in datatracker

Datatracker currently makes the following formats available (e.g., on <https://datatracker.ietf.org/doc/draft-nottingham-http-portal/>):

plain text, xml, pdf, html

A few issues/suggestions:

1. The "main" page for a draft contains only the first ~2 pages of the draft. Does this serve any practical
function? Why not include the whole thing?

2. The "html" version is an html-adorned text/plain draft. Julian's XSLT produces good HTML -- why not link
to it? Or, at least make it available; right now people have to click first on the 'html' version here, then
click on the 'html' version in the resulting page (on tools.) -- very confusing. Ideally, since this is the
Web, the (xslt-generated) HTML version should be the default representation.

3. Julian says that his XSLT is also capable of generating epub files, and with minimal modification,
should be able to generate HTML suitable for input into Amazon's KindleGen program. Can the resulting
files (.epub and .mobi) be lined as alternative formats as well? A growing number of IETFers are using
ebook readers.

If these are desirable changes, I could work on them at the sprint, possible (I'm arriving that day from AU,
and may be quite jetlagged).

Cheers,

--
Mark Nottingham   http://www.mnot.net/
Permalink | Reply | 4 comments |
headers
Julian Reschke | 9 Mar 2011 10:41
Picon
Picon

Re: page breaking - Re: xml2rfc community comments

On 09.03.2011 00:28, Alice Hagens wrote:
> The RFC Production Center agrees with the following 2 comments regarding page breaking in the text output
of xml2rfc.
>
> Christopher Dearlove wrote:
>> ... regarding page control issues. Currently tables can
>> be split (badly) and captions of tables and figures put on
>> separate pages to their table or figure. Less critical, but
>> while I'm on a wish list, I don't like section headings at
>> the foot of a page while the section starts on the next page.
>
> Similarly, John Klensin wrote:
>> better handling of widows and orphans
>> (especially with regard to section title-text and lists with
>> undented headings top my personal list,
>
>
> Julian Reschke wrote:
>>  From the practical point of view: I'd simply not worry about where page breaks end up in internet drafts.
Let the RFC production center deal with it when the time is ripe.
>
> Currently, the RPC deals with it by converting XML to nroff, then handling page breaks using commands in
the nroff.  Historically, the RFC Editor has been encouraged to switch to XML entirely, i.e., abandon the
intermediary nroff step; this would be more feasible if the handling of page-breaking were improved.
>
> Perhaps the RFP could include improved placement of page breaks.
> ...

I absolutely do agree that *if* we have a tool that produces paginated 
text, it should work well. Which means, that it should *automatically*
(Continue reading)

Permalink | Reply | 6 comments |
headers
Simon Perreault | 9 Mar 2011 14:07
Picon
Favicon

vCardXML in xml2rfc

Hi,

In the spirit of "eating our own dog food", I think that the next
xml2rfc should use vCardXML[1] for describing RFC authors. vCardXML is
currently a draft in the VCARDDAV working group. It is an XML
representation of the venerable vCard format, which is used just about
anywhere on the Internet for representing contact information.

Are changes to the xml2rfc format allowed?
Is this feasible?
Can I do anything to help?
Would it make anyone hate me and want to kill me? (e.g. RFC editor staff
probably have tools that work with the current format...)

Thanks,
Simon

[1] <http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml>
--

-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca
Permalink | Reply | 4 comments |
headers
Julian Reschke | 9 Mar 2011 14:28
Picon
Picon

Re: vCardXML in xml2rfc

On 09.03.2011 14:07, Simon Perreault wrote:
> Hi,
>
> In the spirit of "eating our own dog food", I think that the next
> xml2rfc should use vCardXML[1] for describing RFC authors. vCardXML is
> currently a draft in the VCARDDAV working group. It is an XML
> representation of the venerable vCard format, which is used just about
> anywhere on the Internet for representing contact information.

That's an interesting thought.

> Are changes to the xml2rfc format allowed?

This sounds like "who's in charge for changes?" - that's something that 
came up in the context of the xml2rfc rewrite SoW, and I believe the 
answer is: the community.

> Is this feasible?
> Can I do anything to help?
> Would it make anyone hate me and want to kill me? (e.g. RFC editor staff
> probably have tools that work with the current format...)

I think a good initial step would be to write a tool that takes 
xml2rfc+vcardxml and transforms it "down" to xml2rfc (similarly how I 
implement "my" extensions in rfc2629.xslt).

Best regards, Julian
Permalink | Reply | 3 comments |
headers
Marc Blanchet | 9 Mar 2011 16:05
Picon
Favicon

Re: vCardXML in xml2rfc

Le 11-03-09 08:28, Julian Reschke a écrit :
> On 09.03.2011 14:07, Simon Perreault wrote:
>> Hi,
>>
>> In the spirit of "eating our own dog food", I think that the next
>> xml2rfc should use vCardXML[1] for describing RFC authors. vCardXML is
>> currently a draft in the VCARDDAV working group. It is an XML
>> representation of the venerable vCard format, which is used just about
>> anywhere on the Internet for representing contact information.
>
...

>
> I think a good initial step would be to write a tool that takes
> xml2rfc+vcardxml and transforms it "down" to xml2rfc

well, but then there will be no value for an author to do the vcardxml 
since the "native" format that would be floating around will be without.

instead, I would suggest to support both formats for the time being, 
something like:
<author format="vcardxml">
... vcardxml blob
</author>

obviously it would require changes to parsers. but since we are 
rewriting it as I understand, might be a good idea to include the 
support of our own standards in it.

Marc.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane