On Wed, 1 Dec 1999, Oren Ben-Kiki wrote:
> I think the following issues should be decided before we go into debate
> about specific SML features (such as attributes, name spaces, etc.).
>
> I1 - Are all valid SML documents also valid XML documents?
> I2 - Are SML standards to be subsets of the equivalent XML standards?
> I3 - Are SML APIs subsets of XML APIs?

The answer is a function of time, it ranges from 'yes' to 'no'
on all three points -- especially as XML continues to grow.

> Personally, I think the answer to (I1) is "yes". There are many reasons for
> it, but the clinching one (IMHO) is that is SML is not XML, it would never
> catch on.

It will catch on if it meets a business need which XML
cannot provide.  I see SML starting as a simple core,
with experimental extensions (not necessarly XML compatible)
built on.  If the experimental extensions are useful, then
they will be incorporated into people's products.  Certainly
incompatible extensions will have to be *very* useful
to justify the break... however, IMHO, the break should be on
a feature-by-feature basis.

> The answer to (I2) is less clear to me. I'd like to make the case that (I2)
> is worthwhile:
>
> - SML documents would be usable in every XML system out there, not just
> parsers.
> - Acceptance of SML as a standard would be much easier, since SML would be
> merely "a uSeful Simple (Streaming?) Subset of XML".
> - Creating the standards would be much faster. We'd just go through the XML
> ones and erase parts.
>
> The question is, can it be done - or rather, can it be done _well_? Phrased
> differently, is XML so messed up that it is impossible to choose a "good"
> simple subset?

Not sure.

> Take attributes for example. An obvious consequence of (I2) is that SML
> would have to support them. Now, as a rule, I avoid attributes. In fact, my
> applications use only two attributes - "id" and "op" (the latter is related
> to meta-XML issues - expressing the difference between XML trees). But I do
> use these two...
>
> Now, if there was a way to get rid of attributes while preserving (I2)... It
> has been suggested that attributes would be shorthand for sub-elements. This
> breaks (I1); an SML file which uses the long form would not be processed by
> XML processors. Therefore this is not an option. (I1) is not debatable (for
> me).

Why does Joe's proposal break I1?  The compatibility is
injective not surjective.

> Do the anti-attribute people feel that getting rid of attributes is worth
> giving up on (I2)?

Yep.

> Take another issue, namespaces. Here's a proposed subset of the current
> spec: prefixes must be unique inside the whole document. I'd go even further
> and require that prefixes must be unique in any set of documents which are
> processed "simultaneously" by a system. If this means we'd end up with a
> IANA like repository for prefixes, so be it. I doubt that it is a real
> problem in practice.
>
> Issue (I3) is even more complex. Would it be possible to obtain SML's
> benefits in actual implementations if we also require (I3)? I feel pretty
> certain the answer is "yes" for SAX; I'm not familiar enough with DOM. At
> any rate, (I3) would allow SML programs to link with XML libraries,
> something which I feel is as vital for SML acceptance even more then (I2).

Not sure....

;) Clark

I think the following issues should be decided before we go into debate
about specific SML features (such as attributes, name spaces, etc.).

I1 - Are all valid SML documents also valid XML documents?
I2 - Are SML standards to be subsets of the equivalent XML standards?
I3 - Are SML APIs subsets of XML APIs?

Personally, I think the answer to (I1) is "yes". There are many reasons for
it, but the clinching one (IMHO) is that is SML is not XML, it would never
catch on.

The answer to (I2) is less clear to me. I'd like to make the case that (I2)
is worthwhile:

- SML documents would be usable in every XML system out there, not just
parsers.
- Acceptance of SML as a standard would be much easier, since SML would be
merely "a uSeful Simple (Streaming?) Subset of XML".
- Creating the standards would be much faster. We'd just go through the XML
ones and erase parts.

The question is, can it be done - or rather, can it be done _well_? Phrased
differently, is XML so messed up that it is impossible to choose a "good"
simple subset?

Take attributes for example. An obvious consequence of (I2) is that SML
would have to support them. Now, as a rule, I avoid attributes. In fact, my
applications use only two attributes - "id" and "op" (the latter is related
to meta-XML issues - expressing the difference between XML trees). But I do
use these two...

Now, if there was a way to get rid of attributes while preserving (I2)... It
has been suggested that attributes would be shorthand for sub-elements. This
breaks (I1); an SML file which uses the long form would not be processed by
XML processors. Therefore this is not an option. (I1) is not debatable (for
me).

Do the anti-attribute people feel that getting rid of attributes is worth
giving up on (I2)?

Take another issue, namespaces. Here's a proposed subset of the current
spec: prefixes must be unique inside the whole document. I'd go even further
and require that prefixes must be unique in any set of documents which are
processed "simultaneously" by a system. If this means we'd end up with a
IANA like repository for prefixes, so be it. I doubt that it is a real
problem in practice.

Issue (I3) is even more complex. Would it be possible to obtain SML's
benefits in actual implementations if we also require (I3)? I feel pretty
certain the answer is "yes" for SAX; I'm not familiar enough with DOM. At
any rate, (I3) would allow SML programs to link with XML libraries,
something which I feel is as vital for SML acceptance even more then (I2).

Share & Enjoy,

     Oren Ben-Kiki

> On Wed, 1 Dec 1999, James Tauber wrote:
> > How much simpler is the core information set of SML than the core
> > information set of XML?
>
> James, I'm convinced that attributes are broken in XML.   And, the
> last time I looked, InfoSet seems to have inherited this brokenness.

Well, admittedly, the InfoSet is pretty much determined by the reporting
requirements on XML processors.

Regarding the brokenness of attributes, I still maintain that they do make
sense when doing markup of textual content (as opposed to serialisation of
data). So I don't consider them broken, just less useful in data-oriented
application domains.

> I think that any specification cannot possibly produce two
> completely compatible implementations -- especially when
> commercial organizations are selling the product with a
> proprietary licensing agreement.  The need for market
> differentation is too seductive.  In my experience, this
> approach has proven to be utterly hopeless.

So why would SML help, then?

James

On Wed, 1 Dec 1999, Joe Lapp wrote:
> I have another option for us to consider.  It is born of my belief that the
> syntax of attributes is not the problem, it's the semantics that give
> us trouble.

Yes.  Our discussions on the other list clearly showed
this fault line.  Further, our discussion has shown that
attributes are indeed broken in XML.

> Attributes could have (should have) been defined so that the presence of
> attributes is transparent to the application using the parser.
> Attribute syntax should merely have been a semantically equivalent
> shorthand for unstructured elements.  For example, the following two
> elements should have been interchangeably equivalent:
>
>   <product><price>$1.23</price></product>
>
>   <product price="$1.23"/>
>

I like this approach.  Hmm. (scratching his head)

> Instead, XML chose to put attributes and elements in different
> namespaces (P1) and to make attributes unordered (P2) and their
> values normalized (P3).  (P stands for either 'property' or 'problem'.)

You forgot one property:  (P4) property names may not be duplicated.

Wow. Nice summary as to the differences between properties
and elements.  Let me answer twice to these.  The first answer
you will not like, the second one is more "pragmatic".

Philosophy:  Fundamentally, I belive that there is a clear
semantic split between the "coordinates" and the "components",
and I typically use the "attribute" vs "element" to support
this belief.  It has thus far served me well.

    P1  Semantically, they are in a different name space, so
        having them in a different name space via syntax makes
        a ton of sense to me.  I've never had the problem
        distinguishing between the following xpath expressions:
        //element[child-element='val'] and //element[@att='val']

    P2  Where as the elements are taken individually, attributes
        are considered together as a whole, thus ordering does
        not matter.  So, once again, I agree with XML here.

    P3  Never considered normalization.  Hmm.

    P4  Coordinates form a set, where components form
        a bag.  So, I agree with XML here.

Pragmatic:  I'm not sure about this, but let me write
it and then I'll see how I feel about it later.  *smile*

    P1  Since I've never seen, nor used an attribute with
        the same name as a possible child element, mixing
        the namespaces is not a problem.  Hmm.

    P2  Since the ordering does not matter, this need not
        be used by a higher level application processor.

    P3  Never considered normalization.  Hmm.  Joe, could
        you explain this one a bit?  I may have some learning
        to do here.

    P4  In many cases, lists are needed where the result is
        a strict concatination of the various components.
        Thus, multiplicity can be hidden not at the lower
        SML layer but at a higher application layer.

Joe, I think I can move along with you on these.  Your
suggestions seem very sound based on experience.

> We want to design SML so that technologies building on it need not
> distinguish between attributes and elements.  Maybe we could impose
> the following constraints on SML:
>
> (C0) SML processors may not report distinctions between elements
>      and attributes.
> (C1) An element may not contain a child element whose name is the
>      same as the name of one of the element's attributes.
> (C2) When an element has attributes, semantic meaning may not be
>      given to the order in which an element's child elements occur.
> (C3) The characters #xD, #xA, and #x9 are not allowed in attribute
>      values of type CDATA.  Also, non-CDATA attribute types are not
>      supported.

These fixes seem sufficient and necessary.  Sounds like &quot; needs
to be added to the built in entities again.

> Let's test these constraints against our attribute problems:
>
> (T0) First, note that an SML processor could be defined as a layer on top
>      of an XML processor, so we won't violate XML processor conformance.
>      In the markup, attributes are distinct from elements, making it
>      possible to expose this distinction.  We must say, "No no."

Ok.

> (T1) Elements and attributes still belong to different namespaces, but we know
>      those namespaces never intersect.  Without this constraint we couldn't
>      enforce (C0).

Yep.

> (T2) Okay, when an SML document is designed, one must decide whether something
>      is to be represented as an element or an attribute.  DTDs and XML
>      schemas already enforce this.  So for any document type you can
>      know beforehand whether order matters in any element.  When
>      attributes occur, they can be reported in any order, but since
>      order won't matter in this case, no problems occur.

I would add one more:  Attributes are reported before child elements,
in other words, strict document order.

> (T3) We fix canonicalization by only allowing canonical forms.  We keep
>      from having to specify two different rules by disallowing the
>      non-CDATA types.

Ok.

>
> These constraints exchange semantic complexity for syntactic complexity,
> but at least it becomes a non-recurring problem.  (It's solved once
> in the parser and doesn't bubble up into each technology.)

Cool.

For my purposes, if semantic differences prove useful, they can
be added with a backwards-compatible add-on.  Anyway, don't jump
all over this statement quite yet, I have alot of explaining to do.

> I don't want to altogether get rid of attributes for the following reasons:
>
> (R1) XML namespaces depend on them, and we will have to support namespaces,
>      although I might like to live with a subset of the namespace spec.
> (R2) Attributes make XML more readable to humans.  Readability is huge
>      and from my experience seems to be one of the main reasons
>      executive embrace XML -- they can make sense of it.
> (R3) SML needs to be what people commonly use.  We aren't going to change
>      people's habits or inclinations.  If we support attributes, the
>      instant we finalize SML countless organizations could immediately
>      declare compatibility with SML.
>
> But I do see now that allowing attribute may require us to put
> complexity somewhere.

Well.  With this proposal, properties become unmistakeably syntax sugar.

Now comes the "big" question.  I see this as an XML compatibility
module in the parser.  How do you see it?

Best,

;) Clark

> Would you please define the "XML Infoset" or provide a URL for us
> Simpletons who are still coming up to steam.

The XML Infoset[1] is a formal description of the set of information that an
XML processor passes to an application as a result of parsing an XML
document.

Consider the XML:

     <a>&#x41;</a>

The information set would (roughly) consist of

     1. A Document Information Item (saying the root is information item 2
below)
     2. An Element Information Item (with the name "a" and a single child
that is information item 3 below)
     3. A Character Information Item (representing the letter 'A')

Note that this is pretty much the same core information set that the
following XML document would produce:

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE a [
     <!ENTITY foo "A">
]>
<a>&foo;</a>

So you can see that an XML processor hides the complexity of entities
references, character encodings, etc. The information set represents a view
of the document that an application would care about.

Some of the discussion of SML touched on Canonical XML. Canonical XML, put
simply, is an unambiguous re-representation of a core infoset back into XML.
Canonical XML is much simpler than full XML largely because it only
represents a core information set. Using an XML processor similarly
simplifies the view of an XML document.

James

On Wed, 1 Dec 1999, James Tauber wrote:
> How much simpler is the core information set of SML than the core
> information set of XML?

James, I'm convinced that attributes are broken in XML.   And, the
last time I looked, InfoSet seems to have inherited this brokenness.

> I think it is more important that we correct the XML spec to remove any
> ambiguities that cause the incompatibility and take efforts to bring
> processors more in conformance with the spec.

I think that any specification cannot possibly produce two
completely compatible implementations -- especially when
commercial organizations are selling the product with a
proprietary licensing agreement.  The need for market
differentation is too seductive.  In my experience, this
approach has proven to be utterly hopeless.

The source code *is* the specification; it describes
_exactly_ what the meaning is by its behavior.

OTOH, I'd like a formal mathematical description of
the process as well.  However, this I believe is
documentation...

> When you talk about implementing XML, do you mean writing an XML processor?
> I don't see many people wanting to do that anymore. If you mean actual
> systems that use XML, isn't most of complexity handled by the XML processor
> anyway?

In this particular case, I mean using XSL/DOM and other
related technologies to make XML useful.  I feel that
these tools are not quite right, and that simplifying
the XML language is required before we should continue.

> This can be the case, but I still think the XML infoset (which is what
> technologies that build on XML are really building on) hides a lot of the
> complexity.

I'll go have another look at InfoSet.  Thanks for
reminding me about it.

;) Clark

Joe,

I like your pragmatic approach, glad to see you
signed up on this list. I'll comment on your
attributes seperately. ;)

Robert,

I've long held the belief that the source code *is*
the standard, since it provides the authoritative
definition of the process being described.  In fact,
Tom DeMarco (an old timer) states in his red book
that the test plan is the requirement, not any similarly
named documentation produced by committee.  Rather than
code being subject to a standard, I see documentation
being subject to the code.  This, perhaps, may help Joe's
goal of a pragmatic approach.  Competition in this case
happens for the better documentation and support -- not
for the better product.  This being said, perhaps we
should be looking to fork not from James Clark's code,
but from the Apache group's code.   Tracking this
code would be far more pragmatic due to it's immediate
applicability in the Apache web server.

Pavel,

A transformation language is needed.  It just is
a very different kind.  I've done significant
work with XSL -- recently wrote an entire time
recording application using JClark's XT and Apache.
I feel there are some serious changes required,
first of all, killing the random-access requirement
dictated by the specification.

Brad,

Really, a transformation language specific to
this wonderful and powerful syntax is needed.
And, the idea of having the language defined in
the syntax is extremely powerful since it enables
recursion, yacc like programs which I consider
devine.  Also, for embedded systems we need to
be able to generate proofs which give an upper
bound on the time required to transform a given
document for real-time settings.

Clark

At 03:23 AM 12/1/99 -0500, you wrote:
>>Joe Lapp wrote:
>> - Technologies that build on XML often inherit its complexities.  These
>complexities translate to cost and time
>> and headaches.
>
>James Tauber replied:
>This can be the case, but I still think the XML infoset (which is what
>technologies that build on XML are really building on) hides a lot of the
>complexity.
>

Hi James,

Would you please define the "XML Infoset" or provide a URL for us
Simpletons who are still coming up to steam.

TIA,


Bob La Quey

> I think all we're trying to do is to get from point A to point B, where
point A is a world that is suffering
> unnecessarily from XML's complexities and point B is a world that is
largely free of them.

But *who* is suffering from XML's complexities. The developers of
processors? Sure but they are a pretty small number. Who else?

How much simpler is the core information set of SML than the core
information set of XML?

> - The XML spec scares users, developers, and writers alike.  I personally
have heard the sentiment from each of > these parties.  We need to make the
truly important details more accessible to everyone.

Agreed. But we don't need a new spec to do this.

> - I am told that no two XML parsers behave identically for all XML.  Tests
at webMethods of some of the
> extremes of syntax support this claim.  We need to clearly define a subset
that all do support identically.  Users
> sticking to this subset can be assured of universal compatibility.

I think it is more important that we correct the XML spec to remove any
ambiguities that cause the incompatibility and take efforts to bring
processors more in conformance with the spec.

> - Aside from being hard to understand, XML is hard to implement.  Contrary
to its initially stated goal, it is not a
> three week job for the average CS student.  The evidence has already been
sited: those who have written XML
> parsers are still trying to converge on parsers that do the same thing.
We need to define the portion of XML that > is easy to get right.

When you talk about implementing XML, do you mean writing an XML processor?
I don't see many people wanting to do that anymore. If you mean actual
systems that use XML, isn't most of complexity handled by the XML processor
anyway?

> - Technologies that build on XML often inherit its complexities.  These
complexities translate to cost and time
> and headaches.

This can be the case, but I still think the XML infoset (which is what
technologies that build on XML are really building on) hides a lot of the
complexity.

James

At 11:13 PM 11/30/1999 -0800, Pavel Velikhov wrote:
>But now you are duplicating the semantic distinctions between attributes and
>elements of XML.
>Why not consider the following: attributes and elements are semantically the
>same in SML [...]

I'm claiming to have hidden all of the semantics by adding syntactic
constraints.  It does mean that only those named constituents that exhibit
certain constraints on text content may be represented as attributes.  The
parser spits out a name and some text and the application doesn't know the
difference.

Creating the SML in the first place is another issue, but the thing that creates
already needs to know whether to represent a constituent as an attribute.

I still think the semantics are completely hidden under this approach.  Fire
again.
--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@...           http://www.webMethods.com

> I just want us to find a very simple and elegant set of layered underpinnings
> for the vast array of applications that can be hosted on a global distributed
> computing system.
>
> For a moment, stop thinking about technology, algorithms and algebras,
> and try to think of the elements that are common to the set of all
> applications. The "Applisphere" to coin a word. The entire point of
> this lower level stuff is to support applications and make the life
> of the applications developer easier.
>

Yes, that is a great starting point! I propose we start with ground zero,
elements and text nodes only, no attributes, etc, and fix the remaining
confusion that remain from XML:

  - whitespace: there should be a strict policy on whitespace at last.
I think whitespace is real content of XML documents. Don't have good arguments
for the case though.

  - comments: comments should be just that, comments. Skipped by all the parsers
and thrown out. I just had a bug in my code where I was iterating over
elements expecting element nodes and text nodes and was hitting a comment
instead.

- ids and idrefs: I am not sure whether there is an agreement to keep these
guys around or not. I vote for them, it is really hard to manipulate data
that cannot maintain node identities and represent graphs.

Pavel

> I have another option for us to consider.  It is born of my belief that the
syntax of attributes is not the problem, it's the semantics that give us
trouble.
>
> Attributes could have (should have) been defined so that the presence of
attributes is transparent to the application using the parser.  Attribute syntax
should merely have been a semantically equivalent shorthand for unstructured
elements.  For example, the following two elements should have been
interchangeably equivalent:
>
>   ?product??price?$1.23?/price??/product?
>
>   ?product price="$1.23"/?
>
> Instead, XML chose to put attributes and elements in different namespaces (P1)
and to make attributes unordered (P2) and their values normalized (P3).  (P
stands for either 'property' or 'problem'.)
>
> We want to design SML so that technologies building on it need not distinguish
between attributes and elements.  Maybe we could impose the following
constraints on SML:
>
> (C0) SML processors may not report distinctions between elements and
attributes.
> (C1) An element may not contain a child element whose name is the same as the
name of one of the element's attributes.
> (C2) When an element has attributes, semantic meaning may not be given to the
order in which an element's child elements occur.
> (C3) The characters #xD, #xA, and #x9 are not allowed in attribute values of
type CDATA.  Also, non-CDATA attribute types are not supported.

But now you are duplicating the semantic distinctions between attributes and
elements of XML.
Why not consider the following: attributes and elements are semantically the
same in SML,
XML-type semantics on attributes can be defined via a schema language like DTD
(DTD doesn't do the
trick nicely, but some other schema language would). Then if you want the same
semantics of
attributes as XML has now, you just subscribe to this DTD. Otherwise there is no
distinction
between elements and attributes at all, that is attributes are pure syntactic
sugar.

Pavel Velikhov

At 10:17 PM 11/30/1999 -0800, Pavel Velikhov wrote:
>[...] There are a couple things that I personally don't like [...] XQL.

Grrrr.

Actually, I wasn't entirely happy with XQL either.  It's not really a query
language anyway.  The name is unfortunate.  Jonathan Robie is fixing things,
though.  But that's another topic.  XPath threw out some of the baggage and then
added a whole lot more for XPointers unification.  You just can't win.

If it's a true query language you want, you're waiting on W3C XML Query.
--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@...           http://www.webMethods.com

At 10:47 PM 11/30/99 -0800, you wrote:
>> I am not sure about the XSL business. Is it really necessary to duplicate the
>> XSL design?
>
>Not in my opinion. If people want to use XSL, they can use XML.
>
>SML documents would be so trivial to manipulate that I wouldn't think
>that further technologies would be required to simplify the task.
>
>--
>Brad Clawsie  brad@...

So far I agree, but only so far. I have developed one major site using
exactly this approach. I think for now it was the best approach available.
I am not confident that will remain so.

If there were, if we were to invent, a declarative approach as a
replacement for XSL that had the obviousness of an HTML then I
would say for certain that it is a better way to go. I am _not_
convinced that the procedural approach will be better in the long
run although pragmatics requires me to agree with (and code with)
Brad for now.

In the long haul "What" is a better way to spec than "How".
But "What" is a lot harder to get right. I am saying that
procedural programming is what we all fall back on when we
don't have any decent declarative approach. I do not think XSL
is _not_ mecca but assigning a perl script to every tag is not
either.




Bob La Quey

At 09:30 PM 11/30/1999 -0800, Robert La Quey wrote:
>I think much of what Joe is writing is correct ... but I have one huge caveat.
>Attributes are a major problem and very hard to ignore if we need upward
compatibility.
>[...]

I have another option for us to consider.  It is born of my belief that the
syntax of attributes is not the problem, it's the semantics that give us
trouble.

Attributes could have (should have) been defined so that the presence of
attributes is transparent to the application using the parser.  Attribute syntax
should merely have been a semantically equivalent shorthand for unstructured
elements.  For example, the following two elements should have been
interchangeably equivalent:

   <product><price>$1.23</price></product>

   <product price="$1.23"/>

Instead, XML chose to put attributes and elements in different namespaces (P1)
and to make attributes unordered (P2) and their values normalized (P3).  (P
stands for either 'property' or 'problem'.)

We want to design SML so that technologies building on it need not distinguish
between attributes and elements.  Maybe we could impose the following
constraints on SML:

(C0) SML processors may not report distinctions between elements and attributes.
(C1) An element may not contain a child element whose name is the same as the
name of one of the element's attributes.
(C2) When an element has attributes, semantic meaning may not be given to the
order in which an element's child elements occur.
(C3) The characters #xD, #xA, and #x9 are not allowed in attribute values of
type CDATA.  Also, non-CDATA attribute types are not supported.

Let's test these constraints against our attribute problems:

(T0) First, note that an SML processor could be defined as a layer on top of an
XML processor, so we won't violate XML processor conformance.  In the markup,
attributes are distinct from elements, making it possible to expose this
distinction.  We must say, "No no."
(T1) Elements and attributes still belong to different namespaces, but we know
those namespaces never intersect.  Without this constraint we couldn't enforce
(C0).
(T2) Okay, when an SML document is designed, one must decide whether something
is to be represented as an element or an attribute.  DTDs and XML schemas
already enforce this.  So for any document type you can know beforehand whether
order matters in any element.  When attributes occur, they can be reported in
any order, but since order won't matter in this case, no problems occur.
(T3) We fix canonicalization by only allowing canonical forms.  We keep from
having to specify two different rules by disallowing the non-CDATA types.

These constraints exchange semantic complexity for syntactic complexity, but at
least it becomes a non-recurring problem.  (It's solved once in the parser and
doesn't bubble up into each technology.)

I don't want to altogether get rid of attributes for the following reasons:

(R1) XML namespaces depend on them, and we will have to support namespaces,
although I might like to live with a subset of the namespace spec.
(R2) Attributes make XML more readable to humans.  Readability is huge and from
my experience seems to be one of the main reasons executive embrace XML -- they
can make sense of it.
(R3) SML needs to be what people commonly use.  We aren't going to change
people's habits or inclinations.  If we support attributes, the instant we
finalize SML countless organizations could immediately declare compatibility
with SML.

But I do see now that allowing attribute may require us to put complexity
somewhere.
--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@...           http://www.webMethods.com

At 10:17 PM 11/30/99 -0800, you wrote:
>
>
>>
>> Then we build upward toward XSL on both streams ... and it really does not
>> matter how long it takes the development stream to evolve. The stable stream
>> is in place as "All the XML you need to know" and the development stream is
>> in place to insure the something emerges which is "What XML should have
been".
>>
>> I don't expect  the development stream to spring forth full blown over night,
>> after all Linux has been years in development. I see what we are doing as
>> the higher level OS for the global distributed computer system. It may take
>> a while to get it right.
>>
>> What do you guys think?
>
>I am not sure about the XSL business. Is it really necessary to duplicate the
>XSL design? There are a couple things that I personally don't like about XSL:
>
> - XML syntax. If you look at other transformation languages like XML-QL, UnQl,
> they are much easier to read than XSL.
>
> - XQL. I have a bias here, since I participated in a design of another query
>language, but a lot of database folks agree that XQL is not a nice declarative
>query language. To me it is just a language design disaster.
>
>I am not sure about the scope of the SML effort, is it possible to re-evaluate
>XML directions such as XSL?
>
>Pavel Velikhov

Certainly. I was not intending to say we should mimic XSL (although
that is a legitimate reading of the test which I wrote.) Rather my
intent was to say "Let's think thru the transformations, queries, etc
that we want at a higher level using a simpler basis as a starting point".

I just want us to find a very simple and elegant set of layered underpinnings
for the vast array of applications that can be hosted on a global distributed
computing system.

For a moment, stop thinking about technology, algorithms and algebras,
and try to think of the elements that are common to the set of all
applications. The "Applisphere" to coin a word. The entire point of
this lower level stuff is to support applications and make the life
of the applications developer easier.

Right Joe?




Bob La Quey

> I am not sure about the XSL business. Is it really necessary to duplicate the
> XSL design?

Not in my opinion. If people want to use XSL, they can use XML.

SML documents would be so trivial to manipulate that I wouldn't think
that further technologies would be required to simplify the task.

--
Brad Clawsie  brad@...

At 10:03 PM 11/30/99 -0800, you wrote:
>
>
>Robert La Quey wrote:
>>
>> I think much of what Joe is writing is correct ... but I have one huge
caveat.
>> Attributes are a major problem and very hard to ignore if we need upward
compatibility.
>>
>> I see only one solution. SML moves forward as two streams ... call it SML++
or XML--
>> is a pure subset of XML and has attributes. This stream is highly visible and
>> is publicized as what it is "All the XML you really need to know". The other
>> stream SML-- does not use attributes and is a longer range research project
aimed
>> at producing an entire new and significantly simpler high level architecture.
SML--
>> need not be compatible with XML. SML-- is "What XML should have been".
>
>Pavel Velikhov replied:
>I think attributes must go in all SMLs. A solution I like is to allow
attributes
>as syntactic sugar: an attribute is really an element then. However I don't
>have any good idea on how to implement such a thing - i.e. without namespaces
>we cannot really use reserved element names to denote an attribute. Also there
>will be a semantic incompatibility with XML, where SML will allow things that
>XML does not: attributes will have nested content and uniqueness is not
>enforced.
>

We might implement this (syntactic sugar) by having a convertor that will map
SML++ (with attributes) in a well defined and unique way into SML--. Note that
the inverse mapping of SML-- to SML++ is _not_ defined because SML-- is going
to be both syntactically simpler and richer. If we are just talking about
attributes though one should be able to define a mapping which goes both
ways (Pavel, Clark, refresh my math, what is the correct terminology for a
reversible map?)

Nonetheless Joe's prgamatics must be respected. He gets a development
stream with classical attributes. This will not in any way inhibit our
development
of the SML variant that does not have them. And it will help us by making it
possible for SML++ to ride the XML wave. The SML++ stream will generate
resources
to support SML--.

>> I have exchanged a brief message with James Clark stating my intent to use
>> the GPL version of the expat code to develop a parser that will flag anything
>> we do not consider as SML. I would like for starters to consider such a
>> model implementation of an SML parser as a viable initial alternative to the
>> endless haggling that we will be drawn into if we place SML into a formal
>> standards process dominated by vested interests who would love to see the
>> whole ting go away.
>>
>> The parser code will all be GPL but we will control the "official" release
>> of the SML parser/validator. People can fork the code at will (it is GPL
right)
>> but we will choose which patches are to be integrated into the "offical"
>> version. This approach has worked quite well on many Open Source projects,
e.g.
>> Linux and Apache.
>>
>> Standards are deemphasized as compared to interoperable Open Source software.
>>
>
>Oh, but is there a standard for SML already? Is it final? Where can I find it?
>The development model sounds very good.

No there is no standard. That was/is my point. We don't want to wait for one.
We want to write at least some useful code as soon as possible and use the
code as definitive. This is a different model for progress but one with a
strong heritage and great legitimacy. Re Linux, Apache and other Open Source
projects. Many real hackers consider this the "only true way" and disdain
standards committees and their endless haggling.

TimBL's original HTML was not sucessful because it satisfied a standards
committee. It was successful because it worked and a million people
instantly "grokked" it. Standards came after that fact and were
not nearly as important.

With luck SML++, Joe Lapp and Don Park's pragmatic variant will have
that same fate. The when we are ready the apth to SML-- and a clean new
architecture will be prepapared.

Samuarai fight with both hands. SML++ is our short knife for the
in close fighting the pragmatists must do tommorrow at work. SML--
is our long sword which will carve a path into the future.

(That was fun to write! :)

Forward,


Bob La Quey

Robert La Quey wrote:
>
> I think much of what Joe is writing is correct ... but I have one huge caveat.
> Attributes are a major problem and very hard to ignore if we need upward
compatibility.
>
> I see only one solution. SML moves forward as two streams ... call it SML++ or
XML--
> is a pure subset of XML and has attributes. This stream is highly visible and
> is publicized as what it is "All the XML you really need to know". The other
> stream SML-- does not use attributes and is a longer range research project
aimed
> at producing an entire new and significantly simpler high level architecture.
SML--
> need not be compatible with XML. SML-- is "What XML should have been".

I think attributes must go in all SMLs. A solution I like is to allow attributes
as syntactic sugar: an attribute is really an element then. However I don't
have any good idea on how to implement such a thing - i.e. without namespaces
we cannot really use reserved element names to denote an attribute. Also there
will be a semantic incompatibility with XML, where SML will allow things that
XML does not: attributes will have nested content and uniqueness is not
enforced.

>
> I have exchanged a brief message with James Clark stating my intent to use
> the GPL version of the expat code to develop a parser that will flag anything
> we do not consider as SML. I would like for starters to consider such a
> model implementation of an SML parser as a viable initial alternative to the
> endless haggling that we will be drawn into if we place SML into a formal
> standards process dominated by vested interests who would love to see the
> whole ting go away.
>
> The parser code will all be GPL but we will control the "official" release
> of the SML parser/validator. People can fork the code at will (it is GPL
right)
> but we will choose which patches are to be integrated into the "offical"
> version. This approach has worked quite well on many Open Source projects,
e.g.
> Linux and Apache.
>
> Standards are deemphasized as compared to interoperable Open Source software.
>

Oh, but is there a standard for SML already? Is it final? Where can I find it?
The development model sounds very good.

Best regards,
Pavel Velikhov

Hi. I've been following the SML discussion as a lurker in XML-DEV.
I haven't chimed in for the same reason that I hate speaking to large
crowds :)

I think any effort to slim down XML is a smart move. When I first read the
XML specs, I was disappointed that certain aspects of SGML continued
to persist.

My only suggestion would be to never consider an XSL-like technology
for SML. I consider the emergence of XSL to be a key mitigating
factor to the widespread adoption of XML itself. I'm more than happy
to write the trivial perl or scheme code to manipulate SML data directly.

thanks
brad
--
Brad Clawsie  brad@...

>
> Then we build upward toward XSL on both streams ... and it really does not
> matter how long it takes the development stream to evolve. The stable stream
> is in place as "All the XML you need to know" and the development stream is
> in place to insure the something emerges which is "What XML should have been".
>
> I don't expect  the development stream to spring forth full blown over night,
> after all Linux has been years in development. I see what we are doing as
> the higher level OS for the global distributed computer system. It may take
> a while to get it right.
>
> What do you guys think?

I am not sure about the XSL business. Is it really necessary to duplicate the
XSL design? There are a couple things that I personally don't like about XSL:

  - XML syntax. If you look at other transformation languages like XML-QL, UnQl,
	 they are much easier to read than XSL.

  - XQL. I have a bias here, since I participated in a design of another query
language, but a lot of database folks agree that XQL is not a nice declarative
query language. To me it is just a language design disaster.

I am not sure about the scope of the SML effort, is it possible to re-evaluate
XML directions such as XSL?

Pavel Velikhov

I think much of what Joe is writing is correct ... but I have one huge caveat.
Attributes are a major problem and very hard to ignore if we need upward
compatibility.

I see only one solution. SML moves forward as two streams ... call it SML++ or
XML--
is a pure subset of XML and has attributes. This stream is highly visible and
is publicized as what it is "All the XML you really need to know". The other
stream SML-- does not use attributes and is a longer range research project
aimed
at producing an entire new and significantly simpler high level architecture.
SML--
need not be compatible with XML. SML-- is "What XML should have been".

I have exchanged a brief message with James Clark stating my intent to use
the GPL version of the expat code to develop a parser that will flag anything
we do not consider as SML. I would like for starters to consider such a
model implementation of an SML parser as a viable initial alternative to the
endless haggling that we will be drawn into if we place SML into a formal
standards process dominated by vested interests who would love to see the
whole ting go away.

The parser code will all be GPL but we will control the "official" release
of the SML parser/validator. People can fork the code at will (it is GPL right)
but we will choose which patches are to be integrated into the "offical"
version. This approach has worked quite well on many Open Source projects, e.g.
Linux and Apache.

Standards are deemphasized as compared to interoperable Open Source software.

We can use the Linux style of versioning to keep the stable and development
streams
separate i.e.

SML 1.0.nn for the SML++ (stable subset of XML)

SML 1.1.mm for the SML-- with new features e.g. recursion, for the development
stream.

i.e. the middle number ie even for stable (bug fix, minor changes) versions
and  the middle number is odd for the development versions.


Then we build upward toward XSL on both streams ... and it really does not
matter how long it takes the development stream to evolve. The stable stream
is in place as "All the XML you need to know" and the development stream is
in place to insure the something emerges which is "What XML should have been".

I don't expect  the development stream to spring forth full blown over night,
after all Linux has been years in development. I see what we are doing as
the higher level OS for the global distributed computer system. It may take
a while to get it right.

What do you guys think?


Bob La Quey

I think all we're trying to do is to get from point A to point B, where point A
is a world that is suffering unnecessarily from XML's complexities and point B
is a world that is largely free of them.

Here at point A the world has already decided that this thing called "XML" is
the way of the future.  The word "XML" is carrying a huge momentum.  Often
businesses are jumping in only because everyone else is jumping in.  The
momentum is unstoppable.  Fate has been decided.

This is fine.  Many technologies are riding the XML wave.  SML can ride that
wave too.  But only if SML is a technology that supports or embellishes this
thing called "XML."  SML is unlikely to get anywhere in reasonable time if it is
perceived as an alternative to XML.

So let's ride that wave.  Let's do SML to help XML.  If SML spreads along with
XML, and if at the end of the day SML lives up to its purpose, the undesirable
XML tidbits will eventually slip into oblivion.  In the end we will have SML. 
But it will still be called "XML," so you will need to bail if you can't sign up
to a truly altruistic mission.

Okay, here's where I think XML needs help:

- The XML spec scares users, developers, and writers alike.  I personally have
heard the sentiment from each of these parties.  We need to make the truly
important details more accessible to everyone.

- I am told that no two XML parsers behave identically for all XML.  Tests at
webMethods of some of the extremes of syntax support this claim.  We need to
clearly define a subset that all do support identically.  Users sticking to this
subset can be assured of universal compatibility.

- Aside from being hard to understand, XML is hard to implement.  Contrary to
its initially stated goal, it is not a three week job for the average CS
student.  The evidence has already been sited: those who have written XML
parsers are still trying to converge on parsers that do the same thing.  We need
to define the portion of XML that is easy to get right.

- Technologies that build on XML often inherit its complexities.  These
complexities translate to cost and time and headaches.  We need to identify the
XML subset that will not propagate these complexities, thus allowing people the
right to create and hence use simpler technologies.

You may have noticed a common theme.  It seems that the best way to help XML is
to identify a subset -- a subset that meets the above criteria.  I think we need
to be very careful to recognize that a subset of XML is not an alternative to
XML.  To ride the XML wave we have to help XML.

But subsetting gives us more freedom than one might think at first.  In addition
to throwing out syntactic constructs, we can add constraints that XML does not
already have.  But we cannot lift constraints without also begging the wrath of
the W3C and of XML's diehard proponents.  We can point out, for example, that
such constraints are present only for compatibility with SGML -- and then hope
that they erode over time.

Since I work for one of the companies that rides the XML wave, I am obliged to
do everything I can to support XML.  I cannot promote an alternative.

--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@...           http://www.webMethods.com

On Tue, 30 Nov 1999, Don Park wrote:
> By all means.  Don't forget that we have polls we can use.
>
> Also, I think we can schedule a weekly chat to get a good
> clubbish feeling going.  We can use the Event feature for
> that.  Neato.

;)


Clark

I'm very happy to see this effort.  As some of
you may be aware, I'm working on a distributed
bookkeeping system with an associate Dan Palanza.

Also, part time I do software contracting to
support my lifestyle.  Anyway, my first post
on the XML-DEV list was in Febuary, in the post
I cheered the XML effort on, but strongly
cried out against the "document" bias which
has lead towards specifications requiring
random access to XML information.  I hope that
we can avoid such a bias with SML.

As a goal for SML, I'd like to eliminate as
much as possible.  Not that SML may be useful
in and of itself -- but that it may prove to be
a good building block for experimental extensions.

In otherwords, SML becomes the "minimum" baseline
for a modular language -- where we do our best to
make extensions othogonal.  As I see XML
proceeding, it is becoming a big ball of mud.

Also, I'd like to see more of a formal approach
taken; where mathematical descriptions are used.
Not so that the formalism may constrict the
language, but so that it may solidify and provide
a solid foundation upon which we may build.  I
expect something much like group theory to be
created... where we have a hierarchy of models
and proofs that apply to particular sub-trees.
As such, let's take it "S L O W" and do it right.

In addition, I'm not afraid to be XML "incompatible"
if it is done right.  IMHO, the world will follow.
However, I'd like to see our "base" ML be a strict
subset of XML so that there is clear applicability.

Anyway here is my "change-of-mind" for attributes:

   Attributes should be eliminated from the base ML.

   We can make an extension that adds them (as they
   appear in XML) if they prove to be necessary.

On Tue, 30 Nov 1999, Robert La Quey wrote:
> But it does not last long. I feel better already. My main
> reason for interest in SML is this. I think that radically
> simplifying XML will provide a much better basis for building
> a higher level architecture for distributed computing of
> all sorts, including of course the WWW.

Exactly.  My particular focus is bookkeeping.

> I'm much more intrested in the higher level architecture and
> a vision of the web. My passion for the simplest possible ML
> at the bottom stems from the strong (but unproven in this case)
> faith that this will lead to major simplification of the higher
> level stuff.

I whole heartedly agree.

> I think what I need to do is define for my own purposes
> SML-- i.e. w/o attributes then go into expat and delete
> all the stuff not needed to support SML-- and try
> to build a thing like XSLT i.e. takes one SML-- into
> another SML--.

Yep.

> The version of sexpat that I have in mind would act as
> a filter to screen out all the XML variants that have
> kruft and krud (like attributes :) in them. Sort of
> a litmus test for the SML code I want to use as a
> foundation.

Good here.

> I suspect the problem is more one of mathematics and algorithms
> than programming or standards. If I could/can spring the time
> to develop such a demo system then I think I could make my
> case which is now intuitive quite a lot more explicit.

I agree.

Best Wishes,

Clark

Hello there!
	 Its great to have a separate SML list! No ridicule from the hardcore
XML folks :)
	 I really like the SML idea from the start, we should have as simple
markup language as possible for the basic building blocks of the Web. Also
I believe SML will be backed by a much wider community than the document
people. Especially since XML is used more and more as Data Modelling Language.
And hopefully we can clean up XML from all the artifacts that are not
really needed for data modelling.
	 What I really want from SML is a good formalism, that has clean
semantics and a good separation of physical and logical aspects. That didn't
work that well in XML with all the entities, comments, etc. And I would really
like to have one standard for syntax and semantics, I don't think it is a good
idea to replicate XML's infoset troubles. I don't know how much people out there
like to mess with formalisms... Personally I love things like labelled ordered
trees, graphs, etc.
	 Also I am interested in keeping quite some power of XML, such as
node-ids, ability to model graphs (through idrefs), and the schemas. I believe
DTDs are thrown out of SML for now, and I approve of that. With all the
mess they introduced in mixed content, different treatement of attributes and
elements, lack of specialized types, entities, etc. I am glad they are gone.
But at some point I believe SML will need a schema language, also a clean and
concise one, just like SML itself.
	 I do have some old concerns about some XML constructs that are now
considered untouchable, I'll bring them up.

1. Trees vs. Graphs:
XML had the ability to represent graphs, which is quite important in all
sorts of applications. The mechanism used (ids and idrefs) was almost nice
too (see the note below). I think SML should have a similar feature in the
core of the language. I don't have a specific proposal of how this
should be done, but I believe it should be done. Actually, one way that
seems quite nice to me is to specify the non-inclusion relationships (links)
in a layer above SML by giving pairs (or groups ala XLink) of node-ids to
be linked.

2. Node ids:
In XML node-id were always optional and furthermore could be arbitrary, that
is anything can be a node-id. In such case if a system needs to assign node-ids
to every node of the document (a database needs to do that), there is no
guarantee
that synthesized node-ids won't conflict with existing ones. I.e. you can't just
use a simple scheme like "0,1,2...", you would need to check what the oid
has not been assigned before. And sometimes (when you have a fragment of the
document and want to assign ids to nodes) this is impossible to do. Hopefully
such thing can be avoided.

	 Anyway, its great to be able to look at the basics again.
Looking forward to interesting discussions,
Pavel Velikhov
pvelikho@...

I appologize to the sudden shift from XML-DEV.  I felt
there was a freight train of a reaction from the storm
of SML-related messages we posted over the Thanksgiving
weekend, so it was either stay and fight through the
flames or jump out the window with our bare arse intact.

It should take at least two to four days for everyone to
shift over so please make yourself comfortable meanwhile.
You are welcome to make proposals and suggestions as to
how we might proceed.

I am not sure if non-managers can post polls and events
but all the facilities are at your commands.  If you
find that you have any problem using the facilities,
please let me know.

Best,

Don Park    -   mailto:donpark@...
Docuverse   -   http://www.docuverse.com

>But it does not last long. I feel better already. My main
>reason for interest in SML is this. I think that radically
>simplifying XML will provide a much better basis for building
>a higher level architecture for distributed computing of
>all sorts, including of course the WWW.

Assembly language of sort in one sense, a house-cleaning
in another sense.

>I'm much more intrested in the higher level architecture and
>a vision of the web. My passion for the simplest possible ML
>at the bottom stems from the strong (but unproven in this case)
>faith that this will lead to major simplification of the higher
>level stuff.

This is true to certain extent.  It is too easy to fall into
traditional document-centric way of thinking with all the
antique junk lying about.

>I think what I need to do is define for my own purposes
>SML-- i.e. w/o attributes then go into expat and delete
>all the stuff not needed to support SML-- and try
>to build a thing like XSLT i.e. takes one SML-- into
>another SML--.

By all means.  Don't forget that we have polls we can use.

Also, I think we can schedule a weekly chat to get a good
clubbish feeling going.  We can use the Event feature for
that.  Neato.

>PS. A guy just wandered by in my alley and offered to
>clean up a mess in the back for $5.00. I said sure.
>I don't feel much different with most consulting gigs
>which is I suppose one reason why something potentialy
>sweet like SML is appealing.

<g>

Best,

Don Park    -   mailto:donpark@...
Docuverse   -   http://www.docuverse.com

"don park" <donpar-@...> wrote:
original article:http://www.egroups.com/group/sml-dev/?start=1
>
> I ask everyone to pretend to be gentlemen or ladies so that
> we may discuss serious topics in a depressingly somber manner.
>

I promise.

I am already sad :(

But it does not last long. I feel better already. My main
reason for interest in SML is this. I think that radically
simplifying XML will provide a much better basis for building
a higher level architecture for distributed computing of
all sorts, including of course the WWW.

I realize others have very different concerns, but ...

I'm much more intrested in the higher level architecture and
a vision of the web. My passion for the simplest possible ML
at the bottom stems from the strong (but unproven in this case)
faith that this will lead to major simplification of the higher
level stuff.

I think what I need to do is define for my own purposes
SML-- i.e. w/o attributes then go into expat and delete
all the stuff not needed to support SML-- and try
to build a thing like XSLT i.e. takes one SML-- into
another SML--.

The version of sexpat that I have in mind would act as
a filter to screen out all the XML variants that have
kruft and krud (like attributes :) in them. Sort of
a litmus test for the SML code I want to use as a
foundation.

I suspect the problem is more one of mathematics and algorithms
than programming or standards. If I could/can spring the time
to develop such a demo system then I think I could make my
case which is now intuitive quite a lot more explicit.

But I operate as a freelance consultant and I am sure as
you know there is much more financial support for almost
anything else ...

Bob,

PS. A guy just wandered by in my alley and offered to
clean up a mess in the back for $5.00. I said sure.
I don't feel much different with most consulting gigs
which is I suppose one reason why something potentialy
sweet like SML is appealing.

Hello,

Welcome to SML-DEV mailing list, the primary mailing list
for SML developers.

Discussion on this mailing list should be contained to SML
in general and to SML/XML compatibility issues.  General
XML discussions should be brought up in the XML-DEV mailing
list.

I ask everyone to pretend to be gentlemen or ladies so that
we may discuss serious topics in a depressingly somber manner.

The administrator of this mailing list is Don Park, the rascal
who proposed SML in XML-DEV.

Cheers,

Don Park