Re: Syntax Free Models

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

Arofan
>
> I hope I don't speak out of turn here, but it seems to me that sequence is
> absolutely an aspect of syntax that we *must* avoid if we are to create an
> information model that is capable of being expressed freely in various
> syntaxes. Hierarchy, on the other hand, is something that exists within
> specific contexts and can (hopefully) be modelled effectively across
> syntaxes.

You can never speak out of turn, but you need to speak a little more clearly
as I do not understand your comments.

What I have heard to date suggests that there is a confusion as to what
"sequences" are meant to do. What I am trying to do in my draft paper is to
restrict where "sequences" can be defined. I see them as a statement of the
ordering of information sets within a specific type of message. Different
user communities can define different orders without having to redefine the
information sets themselves. What I am trying to achieve is a split from the
current trend of trying to do everything in a single hierarchical DTD to
being able to split out the part of the definition that applies to reusable
things (the information sets and the information units) and those that are
specific to a particular application domain (the messages and their
sequences). This is a problem that has in the past afflicted both the XML
and EDI communities.

There is a large difference between this problem and the other part of the
equation, which is concerned with the relationships between business-level
processes, which is where Keith is, I think, coming from. What I was also
trying to point out was that there is a need for hierarchy at the
business-level as well as within a message. We need to know where the
information in our messages is coming from. Without recording this in our
business models we will not be able to maintain messages properly as we will
have no way of knowing what the implications are for any changes we make to
a message that is the source of information used elsewhere in the business
process chain.

I am unclear about from your comments is whether you are against sequences
within a message, or simply between business processes. To claim that
sequences should not be defined as part of a message definition seems to me
wrong. Can you explain why you seem to think it is not needed.

> I think there is a real danger of confounding hierarchy - which is highly
> variable in many cases - and sequence. These are tightly tied in both XML
> and EDI syntaxes today, but in markedly different ways. It is handy to be
> able to express a hierarchy (or context) with a fixed sequence, but it
would
> severely limit the utility of the models we create if we are deterministic
> about this up front.

I don't see how a "hierarchy" can be a "sequence"! Let me clarify what I
mean by hierarchy, sequences and context, to see if we are talking about the
same things. A hierarchy is something where you can tell from your own
parentage what is related to you and what is not. Therefore you can define
paths from yourself to any other member of the hierarchy. A hierarchical
model restricts the sets of paths that can occur in a given hierarchy. A
sequence can only occur at a single level in a hierarchy. It pre-defines the
order of in which siblings are permitted to occur at that level in a
hierarchy. Context, on the other hand, is not constained by the need for
direct path access - it can provide links between trees. The "parent" of a
derived information set/unit can be seen to be from another hierarchy. In
other words it can be expressed as an XML pointer with a URL in front of the
XML path.  I agree that one man's hierarchy is another man's poison, and the
same applies for sequences. Hence the need to define sets in a way that says
as little as possible about sequence, but with the possibility to allow a
hierarchy between sets to be defined where relevant. Similarly you need to
allow people to define messages as relevant sequences of sets, without
allowing them to define hierarchies for the sets themselves.

I know I am not there in clearly defining all these things yet. In fact
yesterday's release of a revised XML Schema spec with restrictions on set
definitiion has severly dented my ability to define what I would like to be
able to do. How this will work in with defining inter-message relationships
needs to be seen.

Martin