OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: DOCBOOK: Re: Concrete proposal for #480954: Extend textobject toinsert external files


IMHO, XInclude <include parse="xml"/> is useful for collecting 
nodes or nodesets from a number of documents. It can be used 
right away; the biggest problem is actually to customize the 
DocBook DTD to allow an 'include' element in appropriate places.

The XInclude namespace is a non-problem, at least until someone 
else comes along with another <include/> element. But then there's
the parameter entity hack.

Wrt. XInclude and SGML, something similar has already been invented 
in HyTime, http://www.ornl.gov/sgml/wg8/docs/n1920/html/n1920.html. 
A lot of what is being accomplished with XML now was already present 
in HyTime five years ago.

At that time, it was still regarded as something "deep" and 
interesting. It is. See e.g.

http://www.oreilly.com/people/staff/crism/transclu.html (SGML/XML '97)

http://lists.w3.org/Archives/Public/w3c-sgml-wg/1996Dec/thread.html


Kind regards,
Peter Ring


-----Original Message-----
From: ydirson@alcove.fr [mailto:ydirson@alcove.fr]
Sent: Tuesday, November 13, 2001 4:13 PM
To: docbook@lists.oasis-open.org
Cc: docbook@lists.oasis-open.org
Subject: Re: DOCBOOK: Re: Concrete proposal for #480954: Extend
textobject to insert external files


On Tue, Nov 13, 2001 at 08:58:55AM -0500, Norman Walsh wrote:
> 1. Can we limit it to parse=text. I don't think so. If we refer
>    normatively to XInclude, we have to accept XInclude semantics.

Can't we somewhat put the parse attribute to #FIXED ?  That would just
subset the standard - would be easy to do with an architectural form
(and I read somewhere that architectural forms apply to XML too).


>    [...] Is the existence of
>    XInclude a sufficiently strong motivator to provide the functionality
>    that way? It might be, given the semantic issues of encodings and such,
>    but I'm not sure.

If it is, at least people using SGML would somewhat feel left behind I
think :(




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC