Hi,
I don't see how we would fit that in with the spec. It states
"Formatting the output by adding whitespace to produce a pretty-printed,
indented, human-readable form. The exact form of the transformations is
not specified by this specification. Setting this feature to true will set
the feature "canonical-form" to false."
It is of course in WD so you could make a comment to the WG.
We also start to get into the world of pain that is edited
documents. My understanding of the format pretty print is that the output
may well not be valid and that this is desired. A big use case for me
is just element only documents that users want to look at.
> Maybe there needs to two features, one that only works if a DTD/Schema is
> available and one that takes a reasonable 'punt' at what is OK (such as
> the rules below) irrespective of any DTD/Schema if any?
Could you expand on this a little for me? They way I see it is
that even if you insert whitespace where mixed content is allowed you can
still print out an invalid document.
> ie if element must conform to:
> <!ELEMENT s (#PCDATA | s1 | s2)* >
>
> How would you format:
> <node>
> <s><s1/><s2>more text</s2>trailing text</s>
> <node>
The way I had been thinking (I am of course happy to be told I am
wrong :)) is that it did not really matter as long as it was consistent. I
felt that the purpose of this feature was literally to pretty print and
not to worry about validity. With the validation part of DOM Level 3 we
will be able to tell if something is valid. If it is then just printing it
out should provide us with a valid document. Deciding when it is OK to
insert whitespace and still produce a valid document sounds like it might
be quite hard.
Gareth
--
Gareth Reakes, Head of Product Development
DecisionSoft Ltd. http://www.decisionsoft.com
Office: +44 (0) 1865 203192
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
