Re: Comments on the 6 Apr Draft

"Joseph M. Reagle Jr." wrote:
> To test this with a scenario:
> 
> <1>
>    <a/>
>    <b/>
>    <c/>
> </1>
> 
> If we want to encrypt 1, there is a corresponding element information item
> with a children Property including (a,b,c).

Not exactly, the children Property includes also the element content
whitespaces (see Character informations items [1]).

> (And if we defined our own set of information set items not mapped to the
> children property, it'd be "non-standard" and it would permit by definition
> for (a,b) to be encrypted together, without including (c), which I don't
> think is our intent. Also, this set of element information items would
> include the children processing instruction, unexpanded entity reference,
> character, and comment information items that we need.)

The issue reported by Blair [2] can also be applied to text content:

   <2>
     This is my text
   <2>
encrypt the childrens of '2':
   <2>
        <EncryptedData>
            <CipherData>somebase64text</CipherData>
        </EncryptedData>
   </2>
and then add more texts in the element '2':
   <2>
      Hello,
        <EncryptedData>
            <CipherData>somebase64text</CipherData>
        </EncryptedData>
      some other sentences...
   </2>

The encrypted data does no longer represent the content of the element, but a
range in its content. Ranges were first introduced by DOM Level 2 [3], then the
notion was reused in XPointer [4]. For the moment, the Range notion has not
been defined on top of the Infoset but I guess this should be fixed. I guess
the abstract definition could be done on top of the future XPath Data Model
(based on the Infoset/XML Query) [5]. Or you can define your own Range using
the Infoset.
Unlike the Range defined by DOM2, yours can't cross node boudaries. The
following range (represented using '[' and ']') is out of scope of the
encryption goals:
   <3>
      He[llo,
        <a>This is my] text</a>
      some other sentences...
   </3>

In other words, the two containers of the boundary-points must be the same
otherwise it will not be possible to represent the encryptedData in the
document.
from your point of view, in Infoset-speak, a range is defined by two points,
a start point and an end point, contained by the SAME Information item. For
Element Informations items, a point is a position in the ordered list obtained
with the childrens Property. Point is not defined for Character information
items (it contains only one character, therefore it could be defined using its
parent).  (and so on for Comments, ...)

> In DOM, there is a NodeList interface: "The NodeList interface provides the
> abstraction of an ordered collection of nodes, without defining or
> constraining how this collection is implemented. "
> http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-536297177

The NodeList represents an ordered list of nodes in the tree and is used in
several places. One of them is of course to represent the list of childrens of
an element (obtained with the property "childNodes").

> So (and I'm no expert, particularly on DOM) I find it difficult to come up
> with a single "word" and definition that accurately and narrowly captures
> the distinction between and element and its content...?

The DOM doesn't define his abstract model. This was, and still is, the role of
the Infoset recommendation. The DOM contains more informations than the Infoset
(such as CDATA sections), and therefore extends it (but we don't provide an
abstract definition like the Infoset).
 
> In Infoset-speak, we're encrypting an element item or its children property,
> in DOM-speak we're encrypting

in DOM-speak, you're encrypting an Element node or its child nodes.

Regards,
Philippe

[1] http://www.w3.org/TR/2001/CR-xml-infoset-20010514/#infoitem.character
[2] http://lists.w3.org/Archives/Public/xml-encryption/2001May/0028.html
[3]
http://www.w3.org/TR/2000/REC-DOM-Level-2-Traversal-Range-20001113/ranges.html
[4] http://www.w3.org/TR/2001/WD-xptr-20010108/#b2d250b5b9c11c11
[5]
http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001May/att-0094/01-WD-xpath-dm.html

Received on Thursday, 17 May 2001 17:19:11 UTC