Subject: [xml2rfc] xml2rfc 1.7 released
From: [email-masked] (Marshall T. Rose)
Date: Wed, 22 Aug 2001 13:45:43 -0700

http://xml.resource.org is now updated:

1. links for tgz/zip files point to the 1.7 release

2. the include example shows the new "<?rfc include="..." ?> facility

3. a second bibliographic database is available -
http://xml.resource.org/public/rfc/bibxml2/ - these are references to
various ANSI, ISO, et&c., documents taken from many RFCs

new features of 1.7

1. new include facility

2. <?rfc editing="yes" ?> to produce output that makes it easier for folks
to talk about a draft (e.g., "look at paragraph 42 and make this change")

3. various small bug fixes

4. more complete README file

enjoy!

/mtr

From: [email-masked] (Fred Baker)
Date: Tue, 21 Aug 2001 04:49:14 +0800
Subject: [xml2rfc] Query regarding includes
In-Reply-To: <0b8b01c1290a$733aa700$8d53cf3f@FATORA>
References: <[email-masked]>
Message-ID: <[email-masked]>

At 07:55 AM 8/20/2001, Marshall T. Rose wrote:
>the current xml2rfc release is 1.7 -- in
>1.6 i fixed a margins problem with lists.

what I got from http://xml.resource.org/ was 1.6. Where might I find 1.7?

>give me an example of what works for xmlspy. it's easy enough for me to
>update xml2rfc to stop complaining.

XML Spy wants to say something like:

<!DOCTYPE rfc SYSTEM "D:\Documents and Settings\fred\My 
Documents\In-Progress\rfc2629.dtd">

From: [email-masked] (Marshall T. Rose)
Date: Mon, 20 Aug 2001 12:52:39 -0700
Subject: [xml2rfc] Query regarding includes
References: <[email-masked]> <0b8b01c1290a$733aa700$8d53cf3f@FATORA> <[email-masked]> <[email-masked]>
Message-ID: <031001c129b1$ab3f3100$8d53cf3f@FATORA>

>     Scott>   <?xml2rfc include='/path'?>

i'll add this to the next release due out this week. this will solve fred's
problem handily, thanks!

however, the actual syntax will be

    <?rfc include='...' ?>

(that's "<?rfc" instead of "<?xmlrfc", cause "?xml"* is reserved by xml).

> The PI-approach is essentially "linking at the application level",
> which has its drawbacks. Generic parsers cannot interpret the
> instructions and fail to construct a proper infoset.

true.

> For the long run, XInclude (http://www.w3.org/TR/xinclude/) could be
> an alternative. This mechanism provides "linking at the infoset
> level", which means, it is more likely to be supported by generic
> parsers.

agreed.

/mtr

From: [email-masked] (Dirk Kutscher)
Date: 20 Aug 2001 16:37:21 +0200
Subject: [xml2rfc] Query regarding includes
In-Reply-To: [email-masked]'s message of "20 Aug 2001 09:42:06 -0400"
References: <[email-masked]> <0b8b01c1290a$733aa700$8d53cf3f@FATORA> <[email-masked]>
Message-ID: <[email-masked]>

>>>>> "Scott" == slawrence  <[email-masked]> writes:

    Scott> "Marshall T. Rose" <[email-masked]> writes:
    >> there really isn't a "standard" include mechanism in xml, so i took the
    >> pre-processor route of using "%include..." as a hack telling xml2rfc to
    >> recognize things. programs that do dtd/schema validation don't like this
    >> because they don't know about the hack and try to interpret it as an entity.
    >> 
    >> in the long term, having a  "standard" include mechanism is the solution.

    Scott> A suggestion - use a processing instruction:

    Scott>   <?xml2rfc include='/path'?>

    Scott> Shouldn't a validating editor ignore that?

Correct.

The PI-approach is essentially "linking at the application level",
which has its drawbacks. Generic parsers cannot interpret the
instructions and fail to construct a proper infoset.

For the long run, XInclude (http://www.w3.org/TR/xinclude/) could be
an alternative. This mechanism provides "linking at the infoset
level", which means, it is more likely to be supported by generic
parsers.

Having generic parsers resolve include-directives is useful, because
it facilitates the usage of non-proprietary transformation tools.

Until XIncludes is more widely supported (it's current status is W3C
Working Draft), the PI-approach might be a viable work-around.

-- 
	Dirk

From: [email-masked] ([email-masked])
Date: 20 Aug 2001 09:42:06 -0400
Subject: [xml2rfc] Query regarding includes
In-Reply-To: <0b8b01c1290a$733aa700$8d53cf3f@FATORA>
References: <[email-masked]> <0b8b01c1290a$733aa700$8d53cf3f@FATORA>
Message-ID: <[email-masked]>

"Marshall T. Rose" <[email-masked]> writes:

> there really isn't a "standard" include mechanism in xml, so i took the
> pre-processor route of using "%include..." as a hack telling xml2rfc to
> recognize things. programs that do dtd/schema validation don't like this
> because they don't know about the hack and try to interpret it as an entity.
> 
> in the long term, having a  "standard" include mechanism is the solution.

A suggestion - use a processing instruction:

  <?xml2rfc include='/path'?>

Shouldn't a validating editor ignore that?

-- 
Scott Lawrence                            [email-masked]
Virata Embedded UPnP & Web Technology    http://www.emweb.com/

From: [email-masked] (Dan Kohn)
Date: Mon, 20 Aug 2001 00:36:16 -0700
Subject: [xml2rfc] Query regarding includes
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

FYI, in Win2K and WinXP, you can set environment variables by choosing
Start: Settings: Control Panels: System: Advanced tab and then clicking
the Environment Variables button.

		- dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Fred Baker
Sent: Sunday, August 19, 2001 16:22
To: Marshall T. Rose
Cc: [email-masked]
Subject: [xml2rfc] Query regarding includes

Marshall:

So I am madly using xml2rfc on various documents; I really like it. I
have 
wished that I had a tool for sorting out when the XML tags no longer
line 
up; the good news is that I found one, called XML Spy, which is mostly 
pretty good. Life is largely good.

I have found a bug of sorts with the html output, at least under
Netscape. 
When I make lists, in the "edit" view of Netscape I can see that they
are 
lists, and they have numbers or bullets or whatever; in the "browse"
view, 
the bullet is lost. I'm not certain what causes that; I have tried
removing 
your 'class="text"' from the <ul> tag, and have tried removing the
<font> 
tags from the list items, to no obvious avail. For the moment, just
letting 
you know.

In order to get the DTD to be appropriately in sight, I have to put a
copy 
of the DTD in the directory I do my draft editing in. If I (as XML Spy
is 
wont to do) put a fully qualified name in pointing to my copy of the
DTD, 
XML Spy is happy but TCL is not.

The %include facility is also not working for me, and I suspect it has
to 
do with the environment variable somehow. To perform

	%include reference.RFC.2119.xml;

you exercise the code:

#
# whenever "%include.whatever;" is encountered, act as if the DTD
contains
#
#       <!ENTITY % include.whatever SYSTEM "whatever.xml">
#
# this yields a nested (and cheap-and-easy) include facility.
#

     if {[catch { set path $env(XML_LIBRARY) }]} {
         set path [list $inputD]
     }

now I glean from this that I am looking for a directory named
XML_LIBRARY. 
I put the XML Bibliography (thanks!) into such a directory, located in
said 
same directory with the DTD and my source files. Nada - it doesn't find
it.

So my second guess is that "XML_LIBRARY" is an environment variable, and
I 
don't know how to make those happen under W2K.

So - where should I be putting the DTD if not in the directory with the 
file, and where should I be putting the XML Bibliography?

Taking the discussion half a notch higher, is there any harm in
converting 
the DTD to a schema, in the process adding said include capability, and
as 
a result making XML Spy not report that "the DTD doesn't contain a
<!ENTITY 
% include ...> pragma and therefore your XML is incorrect"? Hmm?

_______________________________________________
xml2rfc mailing list
[email-masked]
http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: [email-masked] (Marshall T. Rose)
Date: Sun, 19 Aug 2001 16:55:39 -0700
Subject: [xml2rfc] Query regarding includes
References: <[email-masked]>
Message-ID: <0b8b01c1290a$733aa700$8d53cf3f@FATORA>

This is a multi-part message in MIME format.

------=_NextPart_000_0B88_01C128CF.C656C080
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> So I am madly using xml2rfc on various documents; I really like it. I have
> wished that I had a tool for sorting out when the XML tags no longer line
> up; the good news is that I found one, called XML Spy, which is mostly
> pretty good. Life is largely good.

xmlspy is a great tool. in fact, it's one of the best successes of the whole
xml story...

> I have found a bug of sorts with the html output, at least under Netscape.
> When I make lists, in the "edit" view of Netscape I can see that they are
> lists, and they have numbers or bullets or whatever; in the "browse" view,
> the bullet is lost. I'm not certain what causes that; I have tried
removing
> your 'class="text"' from the <ul> tag, and have tried removing the <font>
> tags from the list items, to no obvious avail. For the moment, just
letting
> you know.

odd. send me a document to look at. the current xml2rfc release is 1.7 -- in
1.6 i fixed a margins problem with lists.

> In order to get the DTD to be appropriately in sight, I have to put a copy
> of the DTD in the directory I do my draft editing in. If I (as XML Spy is
> wont to do) put a fully qualified name in pointing to my copy of the DTD,
> XML Spy is happy but TCL is not.

give me an example of what works for xmlspy. it's easy enough for me to
update xml2rfc to stop complaining.

> The %include facility is also not working for me, and I suspect it has to
> do with the environment variable somehow.

what i do on win2k is this: in the same directory as the file i'm editing, i
put a file called ".xml2rfc.rc". this file (which i've attached) looks like
this:

global env

if {![info exists env(XML_LIBRARY)]} {
    set env(XML_LIBRARY) ";\\home\\rfcs\\include;\\home\\rfcs\\bibxml"
}
set nativeD [file nativename $inputD]
if {[lsearch [split $env(XML_LIBRARY) ";"] $nativeD] < 0} {
    set env(XML_LIBRARY) "$nativeD;$env(XML_LIBRARY)"
}

you can set environment variables under windows, but this is probably
easier.

the first line calls "env" a global to tcl. it's pre-populated with the
environment.

the next three lines look to see if $XML_LIBRARY is defined. if not, it sets
it to three directories: the current directory, /home/rfcs/include, and
/home/rfcs/bibxml. the second one is where i put my personal include files,
and the third is where i put the ones that get automatically generated.

the last four lines look to see if the directory where the source file is
located is in the search path, if not it's added at the front.

> Taking the discussion half a notch higher, is there any harm in converting
> the DTD to a schema, in the process adding said include capability, and as
> a result making XML Spy not report that "the DTD doesn't contain a
<!ENTITY
> % include ...> pragma and therefore your XML is incorrect"? Hmm?

this is a tricky question. i don't think it's dtd or schema specific so
much.

there really isn't a "standard" include mechanism in xml, so i took the
pre-processor route of using "%include..." as a hack telling xml2rfc to
recognize things. programs that do dtd/schema validation don't like this
because they don't know about the hack and try to interpret it as an entity.

in the long term, having a  "standard" include mechanism is the solution.

in the medium term, you can run xml2rfc to expand all the includes and
produce a new xml file that can be given to a validating editor. but then,
you have the problem of merging your changes back into the original source.

or, if altova adds an include facility to xmlspy, i can add something
compatible with that.

it turns out that i don't have the matching tag problem myself because of
the way i edit. i use emacs or vi with xml2rfc running in another window
(double-click on the xml2rfc.tcl icon under windows). in the current
version, the error reporting is pretty good in terms of where the problem
is, i.e., it knows about the include structure and call tell you which
file/line is probably hosed.

still, i agree that xml2rfc should work better with xmlspy.

/mtr

ps: in a couple of weeks, i'll send a note out explaining some of the
features i use in xml2rfc, e.g., slides and editing mode...

------=_NextPart_000_0B88_01C128CF.C656C080
Content-Type: application/octet-stream;
	name=".xml2rfc.rc"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=".xml2rfc.rc"

global env

if {![info exists env(XML_LIBRARY)]} {
    set env(XML_LIBRARY) ";\\home\\rfcs\\include;\\home\\rfcs\\bibxml"
}
set nativeD [file nativename $inputD]
if {[lsearch [split $env(XML_LIBRARY) ";"] $nativeD] < 0} {
    set env(XML_LIBRARY) "$nativeD;$env(XML_LIBRARY)"
}

------=_NextPart_000_0B88_01C128CF.C656C080--

From: [email-masked] (Fred Baker)
Date: Mon, 20 Aug 2001 07:21:46 +0800
Subject: [xml2rfc] Query regarding includes
Message-ID: <[email-masked]>

Marshall:

So I am madly using xml2rfc on various documents; I really like it. I have 
wished that I had a tool for sorting out when the XML tags no longer line 
up; the good news is that I found one, called XML Spy, which is mostly 
pretty good. Life is largely good.

I have found a bug of sorts with the html output, at least under Netscape. 
When I make lists, in the "edit" view of Netscape I can see that they are 
lists, and they have numbers or bullets or whatever; in the "browse" view, 
the bullet is lost. I'm not certain what causes that; I have tried removing 
your 'class="text"' from the <ul> tag, and have tried removing the <font> 
tags from the list items, to no obvious avail. For the moment, just letting 
you know.

In order to get the DTD to be appropriately in sight, I have to put a copy 
of the DTD in the directory I do my draft editing in. If I (as XML Spy is 
wont to do) put a fully qualified name in pointing to my copy of the DTD, 
XML Spy is happy but TCL is not.

The %include facility is also not working for me, and I suspect it has to 
do with the environment variable somehow. To perform

	%include reference.RFC.2119.xml;

you exercise the code:

#
# whenever "%include.whatever;" is encountered, act as if the DTD contains
#
#       <!ENTITY % include.whatever SYSTEM "whatever.xml">
#
# this yields a nested (and cheap-and-easy) include facility.
#

     if {[catch { set path $env(XML_LIBRARY) }]} {
         set path [list $inputD]
     }

now I glean from this that I am looking for a directory named XML_LIBRARY. 
I put the XML Bibliography (thanks!) into such a directory, located in said 
same directory with the DTD and my source files. Nada - it doesn't find it.

So my second guess is that "XML_LIBRARY" is an environment variable, and I 
don't know how to make those happen under W2K.

So - where should I be putting the DTD if not in the directory with the 
file, and where should I be putting the XML Bibliography?

Taking the discussion half a notch higher, is there any harm in converting 
the DTD to a schema, in the process adding said include capability, and as 
a result making XML Spy not report that "the DTD doesn't contain a <!ENTITY 
% include ...> pragma and therefore your XML is incorrect"? Hmm?

From: [email-masked] (Marshall T. Rose)
Date: Fri, 10 Aug 2001 12:21:59 -0700
Subject: [xml2rfc] 2nd test message
Message-ID: <0b4401c121d1$ba6d47d0$8753cf3f@FATORA>

please ignore

/mtr

From: [email-masked] (Marshall T. Rose)
Date: Fri, 10 Aug 2001 01:19:36 -0700
Subject: [xml2rfc] test message...
Message-ID: <07de01c12175$3a2bbe00$8753cf3f@FATORA>

...please ignore

/mtr