RE: ACTION-638: high level reorg suggestions

I've checked in my changes, please note the following in addition to the
intended reorgs, including a number of open editorial and normative
questions worth resolving.

- Changed all references to "Compatibility Mode" and "2.0 Mode" to use that
syntax exclusively

- Added dsig2: to various uses of <code>Selection<code> and other 2.0
elements

- Clarified use of C14N 2.0 "or alternative with a compatible interface" in
various places, please check that I didn't change any intended restrictions
to require use of 2.0 only. The previous language was inconsistent, and in
one case said "2.0 or greater", which seems imprecise.

- Added preamble for 2.0 schema to section 4.

- Substantial reordering and merging of material in the sections on
Selection, Selection Types, and Verification

- Added missing schema snippets

- Changed type of DigestDataLength to nonNegativeInteger (seems more
correct, right?)

- Added new subsections TBD for defining
IncludedXPath/ExcludedXPath/ByteRange elements. The old section on XPath
usage will be merged into those sections, it's commented for now.

I should have time this week to add those TBD sections, but wanted to get
the big revision checked in ahead of the call.

Open Questions:

It seems like we need more text in 4.4.1 on requirements for alternative 2.0
Mode C14N algorithms, much like the section on Compatibility Mode has. Also,
seems like much of that security warning text about arbitrary algorithms
would apply to either mode.

Is Type in Reference also omitted in 2.0 Mode? Left optional? We may need to
move the text around that describes its purpose.

May want to confirm/clarify what we say about comments and PIs: does 2.0
c14n retain PIs? I think we said it disposes of comments, no option?

Spec consistency...do we want to express the Verification children as
type-specific elements, or as a generic element with an Algorithm or Type
attribute? Certainly everything else in the spec tends to use generic
elements. It stuck out a bit when I was editing. Should Selection
"type/subtype" be expressed with a single Algorithm attribute?

Many of the new elements use an <any ##any> content model, instead of a bag
of choices that include known elements and an <any ##other>  wildcard. Is
that intentional? I've probably asked this before...
 
In the section discussing "Subtrees with Optional Exclusions", does the
material on xml:space or xml:base still hold?

-- Scott

Received on Sunday, 5 December 2010 23:28:08 UTC