Re: SD5 - Namespaces - New Version 2

I can see this one use for this in digital signatures, where we need to
determine the scope of the signature.  In Andrew Layman's example he sticks a
digital signature element inside a car element, and I've asked:

1) How we know just what the signature covers.
2) How do namespaces "communicate" where necessary (actually, there's been so
much traffic I'm not even sure if I sent this, but let's suppose I did).

Here we have a way for the document to communicate to whatever is implementing
digital signature exactly what a particular signature covers.  It allows me to
stick an attribute in a node for another namespace and get a logical semantics.

<X:car ... Y:signedElement="me">
  ...
  <Y:dsig  idref = "me>.....</Y:dsig>
</Y:car>

The X namespace processor can see the Y attribute and ignore it, and the Y
namespace processor can find the (to it) opaque element which it has signed.

I think when you put a namespace identifier on an attribute you're getting
_real close_ to an architectural form.

Matthew Fuchs
matt@wdi.disney.com

On May 23,  6:25pm, Paul Grosso wrote:
> Subject: RE: SD5 - Namespaces - New Version 2
> At 15:39 1997 05 23 -0400, Arjun Ray wrote:
> >
> >Sorry, my fault for overloading "qualify". Assuming ':' is the name
> >component separator, I was basically asking about a construction like
> >
> >   ... <X:FOO Y:BAR="baz"> ...
> >
> >where within the same start-tag, an attribute is drawn from some other
> >namespace than the element. Is this kosher?
> >
>
> I don't think you'd want to allow this, and I'm not even sure it makes
> sense:  by definition of what it means to be an attribute (even in
> the natural language sense), how can "an attribute of some element in
> the Y namespace" be an attribute of "the FOO element in the X namespace"?
>
> Actually, please just consider that a rhetorical question (we don't need
> the extra email philosophizing on this concept).  Just explain the user
> requirement this could possibly address if any.
>
> paul
>
>-- End of excerpt from Paul Grosso



--

Received on Friday, 23 May 1997 19:51:28 UTC