Re: verifying order of resources in a document

Mark - let me clarify
----- Original Message -----
From: Mark Bartel <mbartel@thistle.ca>
To: 'tog ' <todd.glassey@www.meridianus.com>; <w3c-ietf-xmldsig@w3.org>
Sent: Friday, July 30, 1999 11:47 AM
Subject: RE: verifying order of resources in a document


> Todd,
>
> I'm not sure I understand.  If you feed a browser an arbitrary chunk of
XML,
> it is unlikely to be able to display it meaningfully.  It could be a
> workflow process definition or it could be a recipe for fudge brownies.

Exactly!

> If
> you attached a style sheet defining how to display the recipe format or a
> workflow definition, the browser could then meaningfully display it.

Making the style sheet a mandatory part of the document or instrument...

> You
> might have another style sheet that displays the recipe in shopping list
> format, in which case it would discard all the cooking instructions and
just
> give the ingredients, perhaps grouped by type.

Which changes the legal context of the instrument or signature represented
by the XML Stream - this is no good either... The signatures need to be
maintained in exactly the same context that they were issued in if they are
relevent to the bigger picture of what the XML stream represents.

> Would the last be non-linear
> processing?  Technically speaking, the browser would still have to go from
> the top through the tag structure to figure it out, so one might still
call
> it top-down.

Except that here the browser becomes the presentation interpreter for the
"XML Stream" and as such part of the envelope of the XML process. Because of
this dependency it has to be part of the spec too if there is commercial
processes or legal ones happening over this transport.

> having an implicit
> knowledge of what the xml data means.  Feed it into the workflow engine
and
> it will allow initiation of that process.

yes !!! and  my concern is that in commercial uses of this particular model,
that the workflow engine will also need a compliance standard, and from a
commercial standpoint be of audited code to be of use in the Industry, per
say.

While this is not directly about the technology use of XML it clearly is
something that as product people that we have to deal with. So if we can
address this in the overall process of defining XML based auth models, we
win bigger I think.

>
> So, it seems to me that the application needs to understand the data,
> whether it does so implicitly (the workflow designer/engine) or it is told
> how (the browser with style sheets).

Yes!

>The order of the data may or may not
> matter; one can rearrange the order of the ingredients of the recipe (a
> set), but it would be undesirable to reorder the instruction steps (a
> sequence).

Yes and along the same axiom, what happens to stage 'a' of a contract if
stage 'b' negates it accidentally. This is the end effect of one such model
where the flow of the construct is not managed. Here is the detail. Step one
of the "contract" says that IF A then NOT B and do execute step C. So if B
is executed first what does this do to the totality of the contract intent
model, in many cases its is flushed essentially. The idea is that there must
be some way to inextricably interpret the object relations irrelevant of
what GOTO features the language supports or its use models are going to be
really hard to get into legislative cover, I think.

I am not saying that this has to be done as part of the pure XML spec, it
can be easily accomplished as a preprocessing operation that flattens a
hierarchical file into what I refer to as a 'resolved XML stream'.

This means that the Digital Signature Aspects of the Language and their core
objects are only specific to single use models and that as they are defined
now they work fine. But I want to reiterate that the refer to the "resolved
version" of the file.

I am actually hacking up a preprocessor that follows the DAO (Digitally
Authenticated Object) XML TAG Processing proposal I made some time ago
(http://www.gmtsw.com/ietf). Personally I think this will work fine and will
allow for multi-dimensional documents like contracts and other legal
instruments to be handled in XML more fully.

By the way, I want to again suggest that a Base64 Encoded BERT Token
(http://www.gmtsw.com/ietf/bert) is one good way to do the timestamping
requirements. It addresses the event, the source of time, its reliability
and chain of custody, and the geographic positioning of the event for
jurisdictional placement. Its free. GNU style license against the Token and
anyone could easily roll an API to produce or verify it.

>
> Could you clarify?
>
> -Mark Bartel
> JetForm Corporation
>
> -----Original Message-----
> From: tog
> To: Mark Bartel; 'John Boyer '; w3c-ietf-xmldsig@w3.org
> Sent: 7/30/99 12:16 PM
> Subject: Re: verifying order of resources in a document
>
> Mark, this actually is a critically important feature of processing XML.
> The issue is specifically that XML as a markup language has no object
> interconnection mechanisms that set order, precedence, or inter/Intra
> Object Control Policy.
>
> What this means is that any XML Stream that is interpreted, MUST be
> interpreted in a top-down, first come-first processed model, and with
> the Core XML spec this only makes sense for applications that need to
> process digital information as though there was a piece of paper there.
>
> But even that is potentially flaky, for instance if I set a browser to
> display in Japanese and pump the standard XML stream into it. It
> displays Kanji in top down and right to left. We read left to right and
then
> top
> down here in the States, so which instrument and which object is processed
> first.  Forget the legal issues here for a minute, and just tell me how
the
> proof models work for representing events in this XML stream that are
> language
> or presentation engine independent.
>
> As to the current vision, I have to ask "Is it the Browser that enforces
> this?" -  So far it is it seems and the value of the digital instrument
> based on this concept is totally leverages against the browser as the
> presentation engine... Take the browser away and the model disintegrates
> making XML no mo' bettah than ASN.1 for writing forms, algs, and
> datastructures in.
>
> Todd
>
> ----- Original Message -----
>
> [deletia]
>
>

Received on Saturday, 31 July 1999 15:06:33 UTC