Two giant thank yous

Mark Ellis mark.uzumati at virgin.net
Mon Nov 26 10:55:26 PST 2001


On 2001.11.24 21:14 Neven Has wrote:
> Hi,
> 
> On Sat, Nov 24, 2001 at 08:28:55AM -0000, cpb at log2.net wrote:
> > Hi Neven,
> > There is no need to reply to this message.
> 
> I think there is. :) There are a lot of good points and suggestions in
> here.
> 
> > Part Two: Possibly reinventing the wheel with <include>.
> >
> > The ALFS-discuss thread about <include> is veering toward the
> reinvention
> > of many wheels, such as:
> >
> > 1) The (draft) XML Inclusions (XInclude) efforts:
> >    http://www.w3.org/TR/xinclude
> >
> > 2) The "Conditional Sections" facility of XML:
> >    http://www.w3.org/TR/REC-xml#sec-condition-sect
> >
> > 3) Picking elements out of an existing XML document is the concern of
> >    XPath: http://www.w3.org/TR/xpath
> >    and XPointer: http://www.w3.org/TR/xptr
> >
> > 4) The names of archive download locations are (almost certainly) URIs,
> >    and URIs are well-defined attribute values in many many elements. So
> >    think twice or even three times before consigning them to
> line-oriented
> >    character data in the element content. (See below for "
> comment)
> >
> > 5) Fetching tar.gz files or whatever from one of a set of download
> >    locations can be viewed as "traversing" an "extended link"
> (generalized
> >    many-to-many hyperlinks) of the XLink recommendation:
> >    http://www.w3.org/TR/xlink
> >
> > 6) I am not trying to just dump homework on you. I have not read all of
> these
> >    TR's in detail, and you need not read them. I don't use namespaces
> and
> >    XSL and XSchema, because frankly they are far too much trouble for
> the
> >    toy uses to which I put XML. But you should think--just like the
> division
> >    between the DTD and the document instance--about the "natural
> domain" of
> >    any further C coding you do. By "domain" I mean think of whether it
> belongs
> >    most naturally to the problem of XML parsing (constructing the
> sequence of
> >    entities/tags/elements/attributes/content), or to the problem of an
> XML
> >    application that consumes the resulting sequence. You may find that
> you
> >    are doing parser work, and you might contribute to some of these W3C
> >    efforts (if indeed you don't already).
> >
> > 7) A concrete example of my concern is this: Do you envision LFS
> profiles
> >    being "processed" or "transformed" (or even "browsed") by some other
> >    generic XML handling program, like Windoze/XMLpad or fed raw to
> Mozilla?
> >    Well the <include> element as discussed/fantasized about on the list
> >    would be a major problem, as it effectively re-introduces the entity
> fetch
> >    stage in the document instance! It is like keeping the compiler
> around at
> >    run time "just in case we forgot to compile something we can just
> eval()
> >    it"
> >    SGML purists would scream at the unification of these stages they
> tried so
> >    hard to keep separate. Might as well call it <magic> (or
> <!ENTITY...).
> 
> Both XInclude and XLink have been mentioned and suggested on the list
> before,
> and I have to admit that I might rushed a bit with implementing <include>
> without giving them more chance. I was probably too impatient to finally
> allow splitting of profiles.
> 
> Since I'm not a XML expert and haven't yet read much of the above
> specifications (but I _will_ do my homework :), I cannot comment much
> on them. You're raising a lot of good points and ideas, but I myself have
> probably more questions than answers on these issues.
> 
> For example, how should we start using them? By implementing them on top
> of
> expat, by switching to other parser like libxml (which supports some of
> the
> above), or use some other libraries (if they exist) etc. etc.
> 

Urgh, i _really don't want to try building these on top of 
expat/XML::Twig, i have little enough time as it is :) I have thought 
about switching the FEBE to libxml defore though, and think i could 
probably do that with minimal effort. The only thing that has really 
stopped me up to this point was the smaller footprint of expat, but since 
alfs definitely seems to be growing I don't suppose this is a very good 
reason anymore.

> I'm willing to try all approaches if needed, if somebody points me to
> the right direction. :)
> 
> --snip --
> 
> Again, since my knowledge of XML (and friends) is pretty basic, I might
> be
> talking pure nonsense here. :)
> 
> I'm definitely going to start digging into this more.
> 

Me too.

> > ----------------------------------------------------------------------
> > Part Three: Expat may have to be patched or abandoned.
> >
> >    I am sorry about the problem with " et al. entity resolution
> >    in expat. I have had to patch expat myself to process documents with
> >    control characters in them. My feeling is that there are some tiny
> bugs
> >    in expat; but that is a serious accusation since James Clark is no
> fool.
> >    But expat may have to be patched or abandoned. Quote handling is
> important
> 
> I never had a problem with " and expat. Perl's FE_BE is the only
> place
> where the problem is visible, so it can only be something with
> XML::Parser
> or XML::Twig. XML::Parser is build on top of expat, but nALFS, which uses
> only expat, doesn't have any problems with " inside attribute
> values.
> I'm just realizing that I haven't yet searched the Net about this issue,
> maybe we could come up with something there? Has anybody already tried
> that?
> 

Doh, hadn't done a search either, just did a quickie but it didn't turn up 
a great deal. The XML::Twig FAQ did have an entry suggesting that it 
escapes all control characters however, which I read as meaning they are 
escaped in the tree. Perhaps not what we expected, but what we've seen 
makes sense, I'd put it down to XML::Twig rather than expat.

Mark
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message



More information about the alfs-discuss mailing list