Re: SD5 - Namespaces (Implementation questions)

At 10:03 18/05/97 GMT, Peter Murray-Rust wrote:
> I regard namespaces as *the* critical problem of the 5 questions - the
>others can all be managed in some way at present; namespaces can't.

I strongly agree with this.

><SOLUTION>
>SUBDOC.  From my reading this allows one to switch DTDs in mid-processing.
>I understand that not all parsers support it.  Having been weaned on sgmls
>I find it supported there, but no explicit documentation on how to use it.
>I also have no idea what the output is.
></SOLUTION>

I don't think SUBDOC solves the problem: people want multiple namespaces in
the same entity.  It also doesn't help with creating DTDs that combine
element types from multiple namespaces.

><SOLUTION>
>AFs and/or HyTime.  I am repeatedly assured by the evangelists - and I believe
>them - that AFs and HyTime will solve all our problems.

The only thing from HyTime that you need for namespaces is AFs, which are
completely independent of the rest of HyTime.

>  This is clearly a 
>millenium solution for SGML, but not for July 1, 1997.

Why not?  It's implemented and people are using it already in the SGML world.

>  Currently it ('it' 
>refers to the universal solution) has the following drawbacks.
>(a) It's not easy to understand, and I don't. [Several people have both 
>talked to me and posted explanations for which many thanks, but I'm a slow 
>learner.]

If you gave some detail about what it is you don't understand, maybe
somebody could try to explain.

>(b) There is no simple introdcution with examples.
>(c) There is no inexpensive working system that I can play around with.

SP has supported AFs for some time.

>(d) I am frightened that the *output* of a HyTime engine (or whatever) is
>sufficiently complex that the post-parsing/application engines must take on a
>further level of sophistication.

You don't need a HyTime engine to do AFs.  The output of an AF engine isn't
much different from an output of a parser.

James

Received on Sunday, 18 May 1997 08:58:02 UTC