Re: Problem: How to encrypt nodes without breaking parsers

At 05:27 PM 10/27/2000 -0400, Joseph M. Reagle Jr. wrote:
>At 20:07 10/2/2000 +0900, Takeshi Imamura wrote:
>>By the way, I heard there was a discussion on the validity of HTML/XML, 
>>that is,
>>how applications should work when detecting unknown vocabularies, and it 
>>a consensus that unknown attributes (and resultant error messages) may be
>>ignored.  Considering this, adding an ID attribute to an element to be 
>>and not changing its content model may not be so serious.
>This might be the case for HTML, with a content model that was often 
>chaotic and laxly interprated. However, I don't see how this would be 
>applied with respect to validity over XML. Such a document would still be 
>well-formed, but not valid as defined by the specifications. (What 
>discussion, and what consensus?)
>This concerns me because if we do have a requirement to not violate the 
>validity of a document, that could constrain us quite a bit and we would 
>have to rely upon references and XPath (and some have expressed XPath can 
>be rather heavy with respect to parsing...)

We were expanding the specification rather than putting a new requirement 
on it.

The proposed requirement was to support the option of making such a 
requirement on
an implementation.  Specifically the requirement was to have another option 
<Reference URI="xxx'>. The use of <Reference URI="xxx'> would forces the 
to add 'Id' attributes to the target document.  I proposed allowing 
<Reference XPath='xxx'>
as an option.  This would provide a means of supporting implementations 
that were forced
not to change the structure of a document because of legacy parsers.  Most 
will not have to live with this constraint and can avoid XPath.  However, 
our company has
a couple of projects were we have to support parsers with very limited 
robustness that are
already in place.

Steve Wiley

>Joseph Reagle Jr.
>W3C Policy Analyst      
>IETF/W3C XML-Signature Co-Chair

Received on Saturday, 28 October 2000 18:47:43 UTC