RE: note on requirements (was RE: verifying order of resources in a document)

John,

Apparently my original post was significantly unclear, as you will see from
my comments...

> Firstly, since digital signatures are in their own namespace, they
shouldn't 
> conflict with the DTD for the rest of the document. If the namespace spec 
> doesn't account for this, then namespaces themselves would seem to be of 
> very limited utility. 

I wasn't saying that signatures would cause conflicts.  I was saying that
they needed to be included in the DTD (or other definition).

> Secondly, DTDs are not required. 

I never said they were.  That's why I kept using expressions such as "DTD
(or other definition)".  There's always a document definition.  Perhaps it
is very loose, perhaps it specified in a format other than a DTD, perhaps it
is merely implied by the application.

> Thirdly, there are lots of languages (e.g. HTML, XFDL) that can have DTDs 
> while still not capturing the order at the level you're thinking of.

Capturing this detail would be one of many reasons why people use definition
formats other than the XML DTD.  

> A form 
> (in either HTML or XFDL) can have any number of field elements
interspersed 
> with elements with other tag names. Something besides the tag name is used

> to identify the element. 

The problems with HTML forms are so great that the XHTML forms group has
decided to start from a clean sheet.  XHTML is very strongly emphasizing
separation of presentation and data, and the issue just doesn't arise.  XFA
forms similarly avoid the problem, with the form definition separate from
the form data, not interspersed.  Interspersing presentation/definition and
data is contrary to the basic philosophy of both the Web and XML.

> Fourthly, what I'm driving at is not just that we should have the option
of 
> adding the signature element inside of the root element (so, for example, 
> XFDL form plus signature element is still XFDL form). I'm driving at the 
> idea that it should be possible for the actual message for which an 
> encrypted hash is generated to be the same kind of XML document as the one

> into which the signature is placed. 

This makes me uneasy.  If you are looking at it from the user perspective,
they will never see the XML anyway.  They will see a form on the screen.  It
does not make a difference to them whether the signature had the xml tag on
it or not.  They probably won't know what XML is.  From a technical
perspective, you can no longer point at what was actually signed, since the
hashes were created over some virtual document.  Finally, this doesn't make
any sense at all when the links in the manifest point into different
documents.

-Mark Bartel

Received on Thursday, 29 July 1999 12:45:40 UTC