175946 - Show namespace declarations, doctype, xml declaration and CDATA section markers in XML prettyprinting (xmlns nodes missing)

Status: NEW

(Core :: XML, defect)

Description

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This is a a breakout from bug 64945. The prettyprint is currently lacking
xml-declartion, the doctype and namespace-attributes. To implement this we need
to add some extension-functions to transformiix and then call them from the
prettyprint stylesheet

Comment 1

[Boris Zbarsky [:bzbarsky]]

*** Bug 177711 has been marked as a duplicate of this bug. ***

Comment 2

[Boris Zbarsky [:bzbarsky]]

*** Bug 203876 has been marked as a duplicate of this bug. ***

Comment 3

[Daniel B.]

Still exists in build 2003053908

Comment 4

[Hixie (not reading bugmail)]

*** Bug 210783 has been marked as a duplicate of this bug. ***

Comment 5

[Nik Clayton]

Still exists in 1.4 (Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4)
Gecko/20030711)

Comment 6

[Emmanuel Bourg]

Attachment: XML Pretty Print Test

Test case for the XML pretty printing. This sample xml document contains a xml
declaration, a doctype declaration and a namespace attribute.

Comment 7

[Lars Huttar]

Just curious, since this bug has existed for over a year, why its status is
still "New"? Also no priority has been assigned.
This surprising missing feature bit me last night and took me over an hour to
figure out that the namespaces that should have been there in my XML really were
there, they just weren't being shown by Mozilla. I would prefer to be using
Mozilla for my default browser, including during XML development, but this is a
stroke against it.
Not to be critical. I understand there is MUCH to do and some things must be
higher priority than others. This is just my comment to advocate for the
importance of getting this functionality working, in order for Mozilla to be a
viable test base for web development.

Comment 8

[Hixie (not reading bugmail)]

This bug is still NEW because nobody has volunteered to fix it.

Comment 9

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Also CDATA section markers are missing. Modified subject to reflect this. See
bug 226786 for some testcase and some images in how IE shows them.

Comment 10

[Peter Van der Beken [:peterv]]

It seems we need these extension functions:

1)
node-set tx:dom-attributes(node-set?)
Returns all attributes (including xmlns attributes) of the node in the argument
node-set that is first in document order. If the argument is omitted, it
defaults to a node-set with the context node as its only member.

2)
boolean tx:is-cdata-section(node-set?)
Returns true if the node in the argument node-set that is first in document
order is a CDATA section node, false if not. If the argument is omitted, it
defaults to a node-set with the context node as its only member.

or

number tx:dom-node-type(node-set?)
Returns the DOM nodeType property of the node in the argument node-set that is
first in document order. If the argument is omitted, it defaults to a node-set
with the context node as its only member.

3)
string tx:xml-version(node-set?)
Returns the version property of the XML declaration of the document of the node
in the argument node-set that is first in document order. If the argument is
omitted, it defaults to a node-set with the context node as its only member.

string tx:xml-encoding(node-set?)
Returns the value of the encoding property of the XML declaration of the
document of the node in the argument node-set that is first in document order.
If the argument is omitted, it defaults to a node-set with the context node as
its only member.

boolean tx:is-xml-standalone(node-set?)
Returns true if the standalone property of the XML declaration of the document
of the node in the argument node-set that is first in document order has value
"yes", false if it has value "no". If the argument is omitted, it defaults to a
node-set with the context node as its only member.

or

string tx:xml-declaration(node-set?)
Returns the xml declaration of the document of the node in the argument node-set
that is first in document order. If the argument is omitted, it defaults to a
node-set with the context node as its only member.


Note that as things are now we're not able to get all the original values as
they appeared in the source (for example for the XML declaration we always set
version to 1.0).

Not sure how we want to handle doctypes :-/.

Comment 11

[Axel Hecht]

I'd rather move away from using an XSLT stylesheet once I have made some progress
on the structure of the output of the stylesheet we have now.
I have two paths, one is doing a xml output with CSS which should like as much as
possible like the one we have now. The other is going directly to a xul tree 
widget, which would look completely different, but might be way faster and even
smaller in run-time size. (The plain xml is significantly smaller already.)
Sadly enough, I trigger layout bugs up to now. Not sure how to file those.
That part of my projects slipped a little lately.

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

If we can move away from XSLT without increasing binary size that sounds good 
to me. The only requirement is that it should be easy to move the code out 
from gklayout.dll once we have a developer.dll to move it into. Though I doubt 
that will be a big problem.

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 261356 has been marked as a duplicate of this bug. ***

Comment 14

[Phil Ringnalda (:philor)]

*** Bug 272118 has been marked as a duplicate of this bug. ***

Comment 15

[Richard Brodie]

*** Bug 312020 has been marked as a duplicate of this bug. ***

Comment 16

[Lars Huttar]

I think it is a mistake to group display of namespaces with display of doctype, xml declaration and CDATA section markers. In the XML information model used by XSLT and XPath, the presence or absence of namespaces is significant: e.g.,
  <foo xmlns="abc">
is a different document from
  <foo>
because the former foo is in a namespace.

That's not true for the XML declaration and CDATA section markers. And usually not for DOCTYPE either (except in the case of default attributes).

Namespace information could be added to the prettyprint without waiting for extra transformiix extensions, which seems to be what has been blocking progress on this bug for years.

Yes, it would be nice to have the prettyprint display everything, but displaying namespace information should be higher priority since it's a matter of correctness; and it should also be quite a bit easier to implement. I have an XSLT stylesheet that displays namespace info without using any extensions, and would be happy to contribute it. It doesn't always put the namespace declarations in the optimal place, but at least its output is correct.

Comment 17

[Lars Huttar]

Let me point out that *all six* of the bugs marked as duplicates of this one are requests to display namespace information. (Add to that my own comment #7.) So I think it's fair to say that there is much more call for displaying namespaces than for displaying the other information in the source document.

Since displaying namespaces is also something that can be done without waiting for transformiix extensions to be added, that makes namespaces a low-hanging fruit with a lot more bang-for-the-buck than the other issues. Therefore I would submit that the namespace display should be split off as a separate bug. And I would be happy to help fix it.

Comment 18

[Lars Huttar]

Sorry, I guess I should have checked my facts a bit.
Displaying namespace info *can* be done without *extensions*, but the fact remains (according to https://bugzilla.mozilla.org/show_bug.cgi?id=94270) that transformiix doesn't support even the standard namespace:: axis.

I was assuming Mozilla's XSLT engine was standards-compliant.

So 94270 would have to be resolved in order to add namespace info.

Comment 20

[Axel Bock]

Hello out there, any updates? this just cost 3 people about 1h, and this behavior is just so crazy unexpected.

Comment 21

[Mykel Scappin]

Is this nearly 20 year old bug going to be fixed? I've just wasted hours debugging my own code trying to figure out why my server wasn't generating XML namespaces, turns out Firefox just doesn't want to show them :laughing_crying: