-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
/ Bob Stayton <[EMAIL PROTECTED]> was heard to say:
|> 3. OTOH, I really do want this to happen before validation. That way I can write
|>
|>
|> Print Title
|> Online Title
|>
|>and have the right thing happen.
|
| On the third hand
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
/ "Eric S. Raymond" <[EMAIL PROTECTED]> was heard to say:
| Norman Walsh <[EMAIL PROTECTED]>:
|> That's valid when the PIs are left in, but results in a non-XML
|> document when profiled. My model forces the input to be well-formed
|> XML and guarantee
--vkogqOf2sHV7VnPd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Norman Walsh <[EMAIL PROTECTED]>:
> What I don't understand off the top of my head Eric, is why you
> abandoned the XML approach when you abandoned XSLT.
Well...I
--9Ek0hoCL9XbhcSqy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Norman Walsh <[EMAIL PROTECTED]>:
> I think I'm willing to live without else. If I want else, I think the
> right answer is a special-purpose XML vocabulary:
>=20
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
/ "Eric S. Raymond" <[EMAIL PROTECTED]> was heard to say:
| Norman Walsh <[EMAIL PROTECTED]>:
|> 1. Entities should be expanded. If users process
[...]
| Right. I know this. This is why I suggested that the facility might belong in
| the XSLT engine
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
/ "Eric S. Raymond" <[EMAIL PROTECTED]> was heard to say:
| Norman Walsh <[EMAIL PROTECTED]>:
|> I think I'm willing to live without else. If I want else, I think the
|> right answer is a special-purpose XML vocabulary:
|>
|>
|>
|>
|>
On Fri, Oct 11, 2002 at 03:09:05PM -0400, Norman Walsh wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Some more thoughts about this issue...
>
> 1. Entities should be expanded. If users process
>
>
>]>
>
> ...
> &chap1;
>
>
>They're going to expec
Norman Walsh <[EMAIL PROTECTED]>:
> I think the right answer is a specialized XML parser that performs a
> variant of the identity transformation. In fact, it does exactly what
> Jirka's profiling code does except that it has a funky serializer that
> outputs the only the necessary parts of it).
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
/ "Eric S. Raymond" <[EMAIL PROTECTED]> was heard to say:
| Norman Walsh <[EMAIL PROTECTED]>:
|> I think the right answer is a specialized XML parser that performs a
|> variant of the identity transformation. In fact, it does exactly what
|> Jirka's pr
Norman Walsh <[EMAIL PROTECTED]>:
> 1. Entities should be expanded. If users process
>
>
>]>
>
> ...
> &chap1;
>
>
>They're going to expect the profiling to apply to the content of
>&chap1;, not just the wrapper script. That means this code needs to be
>i
--y0ulUmNC+osPPQO6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Norman Walsh <[EMAIL PROTECTED]>:
> That's valid when the PIs are left in, but results in a non-XML
> document when profiled. My model forces the input to be well-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
/ Norman Walsh <[EMAIL PROTECTED]> was heard to say:
| 5. You know, I really want this at the URI level.
|
|
|
| ...
|
|
|
| Now we're getting somewhere!
Yep. I hacked this together as a CGI script on my local web server.
You co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
/ "Eric S. Raymond" <[EMAIL PROTECTED]> was heard to say:
|> It's harder to write the "else" cases in this style, but I think a
|> little creativity in the syntax of the condition attributes might
|> alleviate some of those problems.
|
| Propose a syn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Some more thoughts about this issue...
1. Entities should be expanded. If users process
]>
...
&chap1;
They're going to expect the profiling to apply to the content of
&chap1;, not just the wrapper script. That means
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is a hard problem. If it was an easy problem, we wouldn't have to
keep reinventing solutions for it.
Right up front I think you have to choose: are you going to process
XML or are you going to process a character stream. Both are useful
and both
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
/ Daniel Veillard <[EMAIL PROTECTED]> was heard to say:
| I would really prefer to get DocBook fixed to allow proper conditionalization
| at the *markup* level (if the current solution is not sufficient for
| users' needs like Eric), which then will
At 11:33 11/10/2002, Daniel Veillard wrote:
> I don't affirm or deny anything w.r.t. conditionalization needs. I'm
>just stating my position as the guys who implement and maintain the
>friggin' code, okay !
Corr, he's a bad tempered old b isn't he :-)
> I'm not convinced that one need acce
Daniel Veillard <[EMAIL PROTECTED]>:
> On Thu, Oct 10, 2002 at 06:14:59PM -0400, Eric S. Raymond wrote:
> > What would you consider a complete solution to this problem? I'm not
> > wedded to xmlif itself, I just need to get some work done that
> > requires being able to conditionalize stuff. If
Daniel Veillard <[EMAIL PROTECTED]>:
> > You know, there's reason people keep re-inventing mechanisms for this.
> > It's because they need to get work done -- and getting work done often
> > means wanting to conditionalize documents without spending days on some
> > elaborate custom XSLT hack.
>
Daniel Veillard <[EMAIL PROTECTED]>:
> On Fri, Oct 11, 2002 at 05:38:02AM -0400, Eric S. Raymond wrote:
> > xmlif knows nothing about the XML structure of the document. All it `sees'
> > is the processing instructions what is otherwise, from its point of view,
> > a featureless byte stream.
>
>
Daniel Veillard <[EMAIL PROTECTED]>:
> Probably 1.0.22 usually within one month.
Thanks.
> Honnestly 1/ and 2/ are not acceptable. Now if someone decides
> to standardize something like then it's a big mess.
> Moreover if this can be done by a small and fast external preprocessing,
> why tr
Daniel Veillard <[EMAIL PROTECTED]>:
> Now to be relatively specific about as much as I can since I
> don't have any clear picture of how the selection is actually done, it seems
> to be in the line of the previously found standard extention abuses
> like #pragma foobar for Winblows C compilers
Daniel Veillard <[EMAIL PROTECTED]>:
> I'm not convinced that one need acces to the DocType to conditionalize
> *processing* . And I'm definitely convinced that it's useless to try to
> add support for an unstructured processing within an XML toolkit.
The problem with not being able to see the
Daniel Veillard <[EMAIL PROTECTED]>:
> You want to do
> XML process X > xmlsubset transform > web or print
>
> process X standalone can't be done easilly with XSLT, yes.
>
> XML process X + transform > web or print
>
> can be done with XSLT assuming the way
On Fri, Oct 11, 2002 at 06:09:37AM -0400, Eric S. Raymond wrote:
> So I've written a tool that throws away that whole level of structure and
> gets the job done. I'd sure like to develop a better solution, but you
> seem to be intent on denying there is a problem.
I don't affirm or deny anythi
On Fri, Oct 11, 2002 at 06:36:21AM -0400, Eric S. Raymond wrote:
> Daniel Veillard <[EMAIL PROTECTED]>:
> > I'm not convinced that one need acces to the DocType to conditionalize
> > *processing* . And I'm definitely convinced that it's useless to try to
> > add support for an unstructured proces
On Fri, Oct 11, 2002 at 05:38:02AM -0400, Eric S. Raymond wrote:
> xmlif knows nothing about the XML structure of the document. All it `sees'
> is the processing instructions what is otherwise, from its point of view,
> a featureless byte stream.
Then there is no good reason to implement it in
On Fri, Oct 11, 2002 at 04:41:41AM -0400, Eric S. Raymond wrote:
> Daniel Veillard <[EMAIL PROTECTED]>:
> > Now to be relatively specific about as much as I can since I
> > don't have any clear picture of how the selection is actually done, it seems
> > to be in the line of the previously found
On Fri, Oct 11, 2002 at 08:52:01AM +0100, Tim Waugh wrote:
> On Thu, Oct 10, 2002 at 05:43:38PM -0400, Daniel Veillard wrote:
>
> > > (1) You add support for ?if? and friends to xsltproc. Probably the
> > > fastest route to a complete solution.
> > >
> > > (2) You tell me you'll take a patc
On Thu, Oct 10, 2002 at 05:43:38PM -0400, Daniel Veillard wrote:
> > (1) You add support for ?if? and friends to xsltproc. Probably the
> > fastest route to a complete solution.
> >
> > (2) You tell me you'll take a patch from me to implement them. I'd
> > have to learn the xsltproc co
On Thu, Oct 10, 2002 at 06:14:59PM -0400, Eric S. Raymond wrote:
> What would you consider a complete solution to this problem? I'm not
> wedded to xmlif itself, I just need to get some work done that
> requires being able to conditionalize stuff. If you think there's a
> better way to handle th
On Thu, Oct 10, 2002 at 02:42:48PM -0400, Eric S. Raymond wrote:
> Daniel Veillard <[EMAIL PROTECTED]>:
> > This will be in the next libxslt release.
>
> Can you give us a rough timeframe?
When it's ready.
> And what do you expect the release number
> to be?
Probably 1.0.22 usually withi
32 matches
Mail list logo
