[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: John Cowan's view on SAX extensions for ns drafts

• From: David Rosenborg <David.Rosenborg@x...>
• To: XML Dev <xml-dev@i...>
• Date: Wed, 12 Aug 1998 12:16:21 +0100

Peter Murray-Rust wrote:
> 
> One thing that we may have to bear in mind is whether we wish to preserve
> any of the prefixes for subsequent authoring/transformation. For example,
> if FOO is declared with a default namespace of http://foo.org do people
> mind if it gets output as something like NS3:FOO? (where the prefixes run
> from NS1 to NS10 or whatever). Personally - although I would like it - I
> think that's too advanced and that prefixes are expanded and meaningless in
> any transformation.

First I would like to say that I think using a seperate
namespace handler in SAX is an excellent solution.

About preserving prefixes:

That's true if the applications, processing the output of
the transformation, are also namespace aware. However, if
they are not namespace aware, like most existing validation SGML/XML
software, they may rely literally on the prefixes.

In my opinion, it would be nice to have the prefixes reported
by SAX, but that's only for convenience. I could do without it
but then I would have to write a namespace aware postprocessor
that maps the URIs back to the expected prefixes, and throw it
away when the subsequent applications also get namespace aware.

About namespace resolver:

Is it really necessary for the parser to deal with namespaces at
all (if we don't consider namespace aware validation for the moment)?

In a previous posting David Megginson outlined a layered approach
which clearly shows how simple this part of namespace processing
could be. In this model the parser may be namespace aware for
validation purposes but it does not have to for other reasons.

In my opinion, having a namespace resolver in SAX is an overkill.
I'm not saying it wouldn't be useful, just that it shouldn't be
part of the SAX interface. I think it would be sufficient if
the start namespace scope method was just

startNamespaceScope (String prefix, String URI)

and then the application/SAX Filter would have to maintain
a stack of namespaces just as a typical SAX application
keeps a stack of open elements if it is building a tree.

A namespace resolver could be part of the helper classes though.

Also I think the startNamespaceScope events should occur
before the corresponding startElement event since the element
is itself inside the scope it declares.

</David>

______________________________________________________________________
David.Rosenborg@x...                       Stockholm Stock Exchange

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Follow-Ups:
  • Re: John Cowan's view on SAX extensions for ns drafts
    • From: Peter Murray-Rust <peter@u...>
  • Re: John Cowan's view on SAX extensions for ns drafts
    • From: John Cowan <cowan@l...>

• References:
  • Re: John Cowan's view on SAX extensions for ns drafts
    • From: Peter Murray-Rust <peter@u...>

• Prev by Date: Re: [help]xml4j (linux)
• Next by Date: Re: Java class != XML entity
• Previous by thread: Re: John Cowan's view on SAX extensions for ns drafts
• Next by thread: Re: John Cowan's view on SAX extensions for ns drafts
• Index(es):
  • Date
  • Thread