Re: Still Confused - Syntax Neutal Model/Process

["Martin Bryan" <mtbryan@sgml.u-net.com>]

Betty

> I have read your paper and, as always, there are some interesting
> and thought provoking concepts.  I am having a problem putting the
> concepts together.  Note:  I have created YAA (yet another acronym) for
> syntax neutral model (SNM)
>
> For example - you show the following.
>
> <SNM> Order = MessageId, (Sender|SenderRef), (Recipient|RecipientRef),
>       DeliverTo, Item+</SNM>
>
> I don't see any difference really in the above than:
>
> <DTD>
>
> <!ELEMENT Order (MessageId, (Sender|SenderRef), (Recipient|RecipientRef),
>                  DeliverTo, Item+)>
>
> </DTD>
>
> The syntax is slightly different but it is essentially the same as
> a DTD unless I am not reading enough into the <SNM> example.

You are missing the fact that later on I use an (a & b) construct, which is
not permitted in XML. The basic model of the information set is just that -
a set of reorderable information units. Whilst such a concept can be
expressed in XML Schemas and SGML it cannot be expressed by an XML DTD. I
chose to mimic the SGML notation because it is one of the few notations that
allows for the definition of unnamed sets and member-of lists as well as
sequences. Most modelling languages make the mistake of requiring you to
assign a name to each group of components in the sequence. Note that my
model clearly identifies between information sets, information sequences,
and process chains.

> I am also unclear how the properties get attached to the model, i.e.,
> Location [Of="Sender"].

Any modelling language allows properties to be assigned to classes. In XML
terms this is attributes of elements. (In SGML terms you also have data
attributes on entities.) Properties allow reusable classes to be defined.
Sometimes these are good things, sometimes they should be deprecated. The
interesting thing we learnt from the European XML/EDI Pilot Project was that
in most cases such qualifying properties could most usefully be converted
into element names within the XML data stream.

> >From my understanding of your paper, I believe you are advocating having
> the business processes outside the XML data. If I am reading your paper
> correctly, I wholeheartedly believe.

 What I am saying is that you cannot uniquely identify the source of an
answer unless you can reference a specific answer within a specific process.
Therefore you need a referencing mechanism that includes both references to
processes, references to message instances and references to information
units within messages.

Processing should always be defined independently of the data, but should
include standardized mechanisms for referencing data, such as those provided
by XPath, whose role is well illustrated in XSLT.

> Some of the messages I have read, I get the feeling that some in the group
> are thinking that the processing information will be embedded within the
> XML.

Which group are you referring to? This is certainly not the intention of the
DAMSAD team.

>>After, seeing first-hand the complexity and even more important, the
> cost associated with of embedded processing within the data with IETM's I
> would strongly suggest that we have processing external to the data.  I
> would be very skeptical of embedding processes internal to the XML.

Agreed, but what is important is to be able to reference across processes,
and to be able to control process selection based on the contents of a
message generated by an earlier process (without having to repeat the answer
for each process).

Martin