> >What if each XML element were an RDF Resource
> >with an underlying bag of RDF Properties and Values?
> >
That would be great.

> < here is some text called an element name between the < and the
> >
> and here is some more text called the "content" between the > and
the <
> </ here is some text called an element name between the < and the
> >
>
> I don't see the giant distinction every one seems to make bewteen
> these two pieces of text. I want to mark them both up, i.e. I
really
> want to markup element names as well as the content. As far as I am
> concerned they are just two different kinds of content.

You don't need to mark up the element. If you don't want a
distinction, then you should ignore the element.
RDF allows this by using <RDF:Resource>, which says nothing really.
You might as well write:

   <>
     content
   </>

> So let's fool around a little.
>
> <cat> Sam Sam </cat>
>
> OK.

No, this is OK from a human perspective, but a computer doesn't get
it. You say: I have a cat here, and it consists of 'Sam Sam'. Sam Sam
is just the name of the cat, not the cat.

<cat> <id> Sam Sam </id> </cat>

would make much more sense.

> < <cat>
>     <age> young </age>
>     <color> grey </color>
>     <temprament> friendly </temprament>
> > Sam Sam </cat>
>
> What I want to do is qualify a particular kind of cat
> that happens to be Sam Sam. I don't want to just say
>
> <cat> Sam Sam
>     <age> young </age>
>     <color> grey </color>
>     <temprament> friendly </temprament>
> </cat>
>
> which is a statement only about Sam Sam.
>
> I want to say there is a class of cats that have
> the attributes listed. OK, I could use attributes
> but what if I want a more detailed categorization
> (accidental pun, chuckle) e.g.

Attributes wouldn't help either, according to RDF.
They too say only things about the instance, not about the element.

> < <cat>
>     <age> young </age>
>     <color> grey </color>
>     <temprament>
>        <with strangers> scardy </with strangers>
>        <with family> friendly </with family>
>     </temprament>
> > Sam Sam </cat>
>
> Hmm ... attributes sure don't let us build trees
> within the tags without external games. Here I am
> talking about a particular class of cats of wom
> Sam Sam is an instance.
>
> Now suppose I simply say
> <scardy-cat> =
> <cat>
>     <age> young </age>
>     <color> grey </color>
>     <temprament>
>        <with strangers> scardy </with strangers>
>        <with family> friendly </with family>
>     </temprament>
>
> and
>
> <scardy-cat> Sam Sam </scardy-cat>
> <scardy-cat> Poon Tong Sam </scardy-cat>
> <scardy-cat> Doo Wah </scardy-cat>

I'd like to stick to a more conservative syntax:

<class>
   <id> scardy-cat </id>
   <subClassOf> cat </subClassOf>
   <age> young </age>
   <color> grey </color>
   <temprament>
      <with strangers> scardy </with strangers>
      <with family> friendly </with family>
   </temprament>
</class>

<scardy-cat> <id> Sam Sam </id> </scardy-cat>
<scardy-cat> <id> Poon Tong Sam </id> </scardy-cat>
<scardy-cat> <id> Doo Wah </id> </scardy-cat>

With true RDF, the 'class', 'id' and 'subClassOf' elements would have
the rdf namespace to make them special.

I don't think you need special syntax for what you want to do.

Sjoerd Visscher

Note. Members do not submit Notes to W3C; they make Submission requests. A Note is one artifact of an acknowledged Submission request. "

"A Submission request may be rejected by the Director on the following grounds:

• The ideas expressed in the request are poor, may harm the Web, or run counter to the W3C mission.
• The topics addressed in the request lie outside the scope of W3C's Activities.
• The IPR statement made by the Submitting organizations is too restrictive (see W3C's IPR policy). "

At 02:17 PM 10/1/00 -0000, you wrote:
>
>I don't think you need special syntax for what you want to do.
>
>Sjoerd Visscher
>

Thanks, I think you are right. I'd like to get back to this though
when I have the time and look at simple syntax for RDF. Maybe the
syntax is OK if we just pick one of the two, e.g. the Basic Syntax
and not the Abreviated Syntax.

As far as I am concerned the guts of RDF is these few lines found at
http://www.w3.org/TR/REC-rdf-syntax/#model

5. Formal Model for RDF

The RDF data model is defined formally as follows:

There is a set called Resources.
There is a set called Literals.
There is a subset of Resources called Properties.
There is a set called Statements,
       each element of which is a triple of the form
       {pred, sub, obj}

Where pred is a property (member of Properties),
       sub is a resource (member of Resources), and
       obj is either a resource or a literal (member of Literals).

Now that really is pretty simple and very powerful. We need a syntax
that expresses that simplicity and power.

One possiblity is:

At http://www-db.stanford.edu/~melnik/rdf/syntax.html
Sergey Melnik has introduced a

Simplified Syntax for RDF

Pure RDF

RDF follows a property-centric approach. Let the syntax reflect it. Every XML
tag encountered during processing is considered to be a property name, unless
explicitly overriden. For a tag to be a class name, it must carry the XML
attribute rdf:instance.

Example:

<person rdf:instance="uuid:...">
   <name>
      <firstname>Poo</firstname>
      <lastname>Strawman</lastname>
   </name>
   <birthday>1999-05-24</birthday>
   <address>
     <city>Boston</city>
     <street>Who knows</street>
   </address>
</person>

At http://www-db.stanford.edu/~melnik/rdf/fusion.html
Sergy goes on to write "Bridging the Gap between RDF and XML"
where he explores mixing RDF and conventional XML. He
provides a Reference Parser and API for download.

I'd like opinions form the SML-DEV on this and any other
alternative RDF syntax.



Bob La Quey

Hi Mike,

Often in battles there are acts of courage that go unnoticed.
I do appreciate your principled and courageous stand on this.

<quote>
Also, submissions can only be made by the Advisory Committe representatives of
one or more W3C member companies.  My boss is our AC representative, so I should
be able to get a quick reading on whether he would go along with submitting
Common XML.  I can't imagine why he would not.

I'm tempted to agree with Simon ... this is a lot of hassle and we may just be
informed from On High that nonsense such as Common XML consists of "poor" ideas
that would "harm the Web".  But, I'm inclined to do it, if only to smoke out the
Powers that Be, and be assured that I've donated the last microsecond of my time
to these people as soon as they do reject it.

Again, is anyone out there part of a W3C member organization and could plausibly
get their AC representative to collaborate on this?
</quote>

Regards,

Robert E. La Quey, PhD
Chief Technology Officer
Open Source Communications Corporation

Attributes vs. Element is syntax issue in MinML since MinML
model does not distinguish the two.  Mixed content model,
however, is indeed a model issue.

Don

> -----Original Message-----
> From: Paul Tchistopolskii [mailto:pault12@...]
> Sent: Saturday, September 30, 2000 6:14 PM
> To: sml-dev@eGroups.com
> Subject: [sml-dev] MinML revisited.
>
>
>
> Hello,
>
> Just thinking, why did we tried to find the 'silver bullet'
> MinML API. Maybe it could make sense to have
> multiple models, like MinML model, 'Attributes-only'
> model, 'Mixed context' model, e t.c.
>
> Rgds.Paul.
>
>
>
> post: sml-dev@eGroups.com
>
> unsubscribe: sml-dev-unsubscribe@eGroups.com
>
> info: http://www.egroups.com/group/sml-dev/info.html
>

I liked both of Sergey Melnik's work.  Did W3C make any
comments regarding them?  All I know is that TimBL made
some negative comments regarding RDF.

Don

> -----Original Message-----
> From: Bob La Quey [mailto:robertl1@...]
> Sent: Sunday, October 01, 2000 8:37 AM
> To: sml-dev@egroups.com
> Subject: Re: [sml-dev] Re: HyperXML
>
>
> At 02:17 PM 10/1/00 -0000, you wrote:
> >
> >I don't think you need special syntax for what you want to do.
> >
> >Sjoerd Visscher
> >
>
> Thanks, I think you are right. I'd like to get back to this though
> when I have the time and look at simple syntax for RDF. Maybe the
> syntax is OK if we just pick one of the two, e.g. the Basic Syntax
> and not the Abreviated Syntax.
>
> As far as I am concerned the guts of RDF is these few lines found at
> http://www.w3.org/TR/REC-rdf-syntax/#model
>
> 5. Formal Model for RDF
>
> The RDF data model is defined formally as follows:
>
> There is a set called Resources.
> There is a set called Literals.
> There is a subset of Resources called Properties.
> There is a set called Statements,
>       each element of which is a triple of the form
>       {pred, sub, obj}
>
> Where pred is a property (member of Properties),
>       sub is a resource (member of Resources), and
>       obj is either a resource or a literal (member of Literals).
>
> Now that really is pretty simple and very powerful. We need a syntax
> that expresses that simplicity and power.
>
> One possiblity is:
>
> At http://www-db.stanford.edu/~melnik/rdf/syntax.html
> Sergey Melnik has introduced a
>
> Simplified Syntax for RDF
>
> Pure RDF
>
> RDF follows a property-centric approach. Let the syntax reflect
> it. Every XML tag encountered during processing is considered to
> be a property name, unless explicitly overriden. For a tag to be
> a class name, it must carry the XML attribute rdf:instance.
>
> Example:
>
> <person rdf:instance="uuid:...">
>   <name>
>      <firstname>Poo</firstname>
>      <lastname>Strawman</lastname>
>   </name>
>   <birthday>1999-05-24</birthday>
>   <address>
>     <city>Boston</city>
>     <street>Who knows</street>
>   </address>
> </person>
>
> At http://www-db.stanford.edu/~melnik/rdf/fusion.html
> Sergy goes on to write "Bridging the Gap between RDF and XML"
> where he explores mixing RDF and conventional XML. He
> provides a Reference Parser and API for download.
>
> I'd like opinions form the SML-DEV on this and any other
> alternative RDF syntax.
>
>
>
> Bob La Quey
>
> post: sml-dev@eGroups.com
>
> unsubscribe: sml-dev-unsubscribe@eGroups.com
>
> info: http://www.egroups.com/group/sml-dev/info.html
>

----- Original Message -----
From: Don Park <donpark@...>


> Attributes vs. Element is syntax issue in MinML since MinML
> model does not distinguish the two.

Attributes are unique. This is model issue, I think.

Rgds.Paul.

> Don
>
> > -----Original Message-----
> > From: Paul Tchistopolskii [mailto:pault12@...]
> > Sent: Saturday, September 30, 2000 6:14 PM
> > To: sml-dev@eGroups.com
> > Subject: [sml-dev] MinML revisited.
> >
> >
> >
> > Hello,
> >
> > Just thinking, why did we tried to find the 'silver bullet'
> > MinML API. Maybe it could make sense to have
> > multiple models, like MinML model, 'Attributes-only'
> > model, 'Mixed context' model, e t.c.
> >
> > Rgds.Paul.
> >
> >
> >
> > post: sml-dev@eGroups.com
> >
> > unsubscribe: sml-dev-unsubscribe@eGroups.com
> >
> > info: http://www.egroups.com/group/sml-dev/info.html
> >
>
> post: sml-dev@eGroups.com
>
> unsubscribe: sml-dev-unsubscribe@eGroups.com
>
> info: http://www.egroups.com/group/sml-dev/info.html
>

----- Original Message -----
From: Don Park <donpark@...>

> I liked both of Sergey Melnik's work.

I can not say I like it.

From the page:

"RDF follows a property-centric approach. Let the syntax reflect it."

But  then *elements* are used. To me 'property-centric'
means 'based on *attributes*'.

Rgds.Paul.

> > Attributes vs. Element is syntax issue in MinML since MinML
> > model does not distinguish the two.
>
> Attributes are unique. This is model issue, I think.

One can think of attributes as arrays with first entry (index 0) as
the default value.  When converted to attribute-friendly syntax, remaining
entries are either lost or written out as elements.

- Don

> > > Attributes vs. Element is syntax issue in MinML since MinML
> > > model does not distinguish the two.
> >
> > Attributes are unique. This is model issue, I think.
>
> One can think of attributes as arrays with first entry (index 0) as
> the default value.  When converted to attribute-friendly syntax, remaining
> entries are either lost or written out as elements.

I don't understand what it buys. The good thing about
properties is that the only thing  needed  is a hashtable ...
well ... almost ...

In the universe of attribute-only data structures, lists
could be implemented in the way SQl implements lists
( everything with the same 'id' belongs to the same list ).

In fact, attribute-only XML is like SQL, but it is a bit
'better' ( hashtable always has a 'name' ).

<element1 attr1="some" attr2="some2"/>
<element1 attr1="some" attr2="some2"/>
<element2 attr1="some" attr2="some2"/>

More complex:

<A>
<B>some</B>
<C>
     <C1>some</C1>
     <C2>some</C2>
</C>
</A>

Becomes :

<A B="some" C="link(C)" />
<C C1="some" C2="some"/>

Or even ( not XML ):

<A B="some" C=<C C1="some" C2="some"> />

I don't know.  I feel that 'attribute-only' model
could be as important as 'elements-only'
model of MinML is. I mean when your data are
'attributes only' - do you need *more*
than 'attributes only' ? The usecase when
all you need is  'attributes-only' looks not
too exotic to me.

Let me explain why this craziness suddenly
appeared in my head.

Let us say that we have 3 models.

1. Attributes-only.

API:             API's are simple. Node == hashtable.
Mapping:      Some ( wide range of ) data structures
                    are not easy to map.

2. Elements-only. ( Min ML )

API:              A bit more complex. ( Think about DOM ).
Mapping:       Better ( maybe much better ), but *still*
                     some structures are not easy to map
                     ( mixed content ).

3. XML without entities, DTD's and other macroprocessing stuff,
but with mixed content. ( Common XML ? )

API.             I think extremely complex. ( DOM, Xpath e t.c. e t.c.  ;-)

Mapping       Probably it allows 'convinient' mapping of any data structure,
                    but working with DOM is too hard. I have stopped
                    using DOM  in my projects, because I found that
                    I anyway need to map DOM into my internal structures
                    ( speed  and memory ). Because I can do that mapping
                    on the level of SAX and it is easier to me than to
                    do that mapping on the level of DOM - ... Alas...
                    I don't need DOM - this means complexity of the
                    model *kills* the API. At least for me.

The cost of 'convenient mapping' is the complexity of the API.
For many cases "Attributes-only" model + maybe some
trick ( like 'link()' ) is all I need.

Well,  even SQL was more restrictive than "Attributes-only"
model - SQl had a good life. I think  that was because
APIs were 'good'.

I dont; see  a conclusion yet. The stuff in my head is
kind of 'YML revisited' and I'm not sure it is the appropriate
time to talk  about YML.

Rgds.Paul.

Paul Tchistopolskii [mailto:pault12@...] wrote:

> 1. Attributes-only.
>
> API:             API's are simple. Node == hashtable.
> Mapping:      Some ( wide range of ) data structures
>                    are not easy to map.
>
> 2. Elements-only. ( Min ML )
>
> API:              A bit more complex. ( Think about DOM ).
> Mapping:       Better ( maybe much better ), but *still*
>                     some structures are not easy to map
>                     ( mixed content ).
>
> 3. XML without entities, DTD's and other macroprocessing stuff,
> but with mixed content. ( Common XML ? )
>
> API.             I think extremely complex. ( DOM, Xpath e t.c. e t.c.
;-)
>
> Mapping       Probably it allows 'convinient' mapping of any data
structure,

Nice summary.

> The cost of 'convenient mapping' is the complexity of the API.

I think we have the following options:

- Inconvenient mapping, simple API, simple XML syntax (MinXML).

- Convenient mapping, complex API, XML syntax (CommonXML).

- Convenient mapping, simple API, awkward XML syntax (IndustrialXML).

- Convenient mapping, simple API, non-XML syntax (YML).

That is, convenient mapping costs _something_ - either a more complex API, a
more complex syntax, or a break with XML-compatible syntax.

Oren Ben-Kiki

At 06:26 PM 10/2/00 -0700, you wrote:
>
>----- Original Message -----
>From: Don Park <donpark@...>
>
>> I liked both of Sergey Melnik's work.
>
>I can not say I like it.
>
>From the page:
>
>"RDF follows a property-centric approach. Let the syntax reflect it."
>
>But  then *elements* are used. To me 'property-centric'
>means 'based on *attributes*'.
>
>Rgds.Paul.
>

No Paul,

You are just being stuck in your thinking.

Here is what Sergey is saying.

RDF (as shown is the previous examples) is really nothing
more than a named bag of (Property, Value) pairs. A Value
can be a Resource so the system allows for indirection and
can just be used to build arbitrary networks.

<property>value</property>
...

i.e. elements is a perfectly reasonable way to describe
a bag of (Property, Value) pairs so let that be the default
representation.

Now sometimes you have a element which is NOT a property
but is instead an rdf subject so you annotate that property
with the rdf:resource=URI attribute, e.g.

<cat rdf:resource="http://www.animals.com/cat">
      <color>gray</grey>
      <name> Sam Sam </name>
</cat>

I now, for the first time see a reasonable time and place
to use attributes in a consistent way.

Consider attribute free XML. Now the purpose of attributes
is to "mark up the elelents".

<mantra>
    Elements markup the content (the Values)
    Attributes markup the Elements.
</mantra>

It is as simple as that.

So I now, for the first time, accept attributes as having
a useful role in XML and see a very clear cut statement of when
and where to use them.

Now what Sergey Melnik has noticed is that one
can take existing XML and mark it up in a completely
unambiguous way for RDF interpretation by using

  1) the default rule that an element with content
     defines a (Property, Value) pair

  2) three names in the rdf Namesapce as
     attributes to markup the XML elements in an
     unambigous way.

This is good, strightforward and simple.

I like it. I do think you should seriously reconsider
your opinion.

Your statement:
    "To me 'property-centric' means 'based on *attributes*'.
completely misses Sergey's point. That is not what Sergey
means by 'property centric'.

Regards,

Bob La Quey

PS. I belive what Tim BL is saying, which I certainly believe,
is that the RDF Data Model is sweet, simple and powerful, but
the XML syntax in the Recommendation is terrible. It is a sad
state of affairs. If I were to speculatate I would guess that
what we have in the Rec is a clssic example of a committee
tasked to design a mouse and producing a camel.
Bob La Quey

--- In sml-dev@egroups.com, Bob La Quey <robertl1@h...> wrote:

> >> I liked both of Sergey Melnik's work.
> >
> >I can not say I like it.
> >
> >From the page:
> >
> >"RDF follows a property-centric approach. Let the syntax reflect
it."
> >
> >But  then *elements* are used. To me 'property-centric'
> >means 'based on *attributes*'.
> >

> No Paul,

> You are just being stuck in your thinking.

Maybe. I'l try to explain. ;-)

> Here is what Sergey is saying.
>
> RDF (as shown is the previous examples) is really nothing
> more than a named bag of (Property, Value) pairs. A Value
> can be a Resource so the system allows for indirection and
> can just be used to build arbitrary networks.

> <property>value</property>
> ...
>
> i.e. elements is a perfectly reasonable way to describe
> a bag of (Property, Value) pairs so let that be the default
> representation.

1. Elements are longer to type. ;-)
2. Elements are harder to process with standard XML API's ( SAX
startElement receives Attributes, so processing Attributes-only
XML with current SAX is trivial. It is not so trivial with elements.

But this is not a big deal. See below.

> Now sometimes you have a element which is NOT a property
> but is instead an rdf subject so you annotate that property
> with the rdf:resource=URI attribute, e.g.

> <cat rdf:resource="http://www.animals.com/cat">
>      <color>gray</grey>
>      <name> Sam Sam </name>
> </cat>

<cat rdf:resource="http://www.animals.com/cat"
        color="gray"
        name="Sam Sam"
/>

> Consider attribute free XML. Now the purpose of attributes
> is to "mark up the elelents".

> <mantra>
>    Elements markup the content (the Values)
>    Attributes markup the Elements.
> </mantra>

> It is as simple as that.

'Element is a hashtable' is even simpler. And more efficient.
I don't care about the syntax, actually. If model is not hashtable-
based - no matter what syntax will be used. The complexity is already
there.

> Now what Sergey Melnik has noticed is that one
> can take existing XML and mark it up in a completely
> unambiguous way for RDF interpretation by using
>
>  1) the default rule that an element with content
>     defines a (Property, Value) pair
>
>  2) three names in the rdf Namesapce as
>     attributes to markup the XML elements in an
>     unambigous way.
>
> This is good, strightforward and simple.

The question is how often do we need more than set of unique
properties. In fact, I think because it seems RDF usually needs only
attributes, it could be 'almost hashtable / attributes only', but
when it is not enough - elements could be used.  Or something like
that.

> I like it. I do think you should seriously reconsider
> your opinion.

I will reconsider if I see that RDF is almost about
not-unique children ( children with the same name ) -
*this* need elements.

Sofar I see that RDF is mostly about unique children
( 'properties' ) - this means Attributes should be
used, because the semantics of attribute is 'unique child'.

Mapping properties into atributes is kind of consistent - when
something is consistent it could make 'most of the things' 'easier'.
I dunno.

> Your statement:
>    "To me 'property-centric' means 'based on *attributes*'.
> completely misses Sergey's point. That is not what Sergey
> means by 'property centric'.

Honestly,  I agree that using elements  + attributes
for markup has some elegance.

But now comes the most important point.

I still don't understand why do I need RDF ?

I don't see how can RDF help me with my current stuff ( powerfull-
config-driven-fast-components ).  I'm mapping my config files into
hashtables and arrays of hashtables. This model works darn efficient
and configs are still 'natural'. The drawback is that some
decompositions of XML data are not *that* obvious. It is like it was
with SQL. SQL requires us to make some 'not natural' decomposition of
our data - ( 'not obvious mapping' ) but then processing is efficient.

I'm now mapping everything into hashtables + arrays of hashtables. I
*had* to introduce the 'array of hashtables' in my model, because
without that entity some of decompositions were impossible.

I see no sign of similiar attempts in RDF. Of course, it is possible
to invent something 'simple' and/or 'easy to read' and/or 'elegant' -
whatever.

The ( maybe small?) problem is that after that 'something' is on the
paper somebody should implement that 'something'.

What are RDF implementations ( tools ) and how can I benefit from
those implementations in my 'config-driven' world ?

Actually, I feel that I don't understand something obvious, because
I'm too concentrated on writing that 'config-driven stuff'. Writing
Java webserver which is as fast as Apache could be a bit brainwashing
occupation. ;-) .. Yes... Maybe I'm too concerned on efficiency ...
Sorry if this is the case ;-)

Rgds.Paul.

Oren - you are reading my fuzzy feelings and then you produced
the accurate conclusion.

Rgds.Paul.

PS. I think maybe we've made a mistake killing YML.

PPS. When I say "XML" I am already thinking in terms of SAX events /
nodesets, not in terms of < / > ( there is no < in SAX
event ;-)

--- In sml-dev@egroups.com, Oren Ben-Kiki <orenbk@r...> wrote:
> Paul Tchistopolskii [mailto:pault12@p...] wrote:
>
> > 1. Attributes-only.
> >
> > API:             API's are simple. Node == hashtable.
> > Mapping:      Some ( wide range of ) data structures
> >                    are not easy to map.
> >
> > 2. Elements-only. ( Min ML )
> >
> > API:              A bit more complex. ( Think about DOM ).
> > Mapping:       Better ( maybe much better ), but *still*
> >                     some structures are not easy to map
> >                     ( mixed content ).
> >
> > 3. XML without entities, DTD's and other macroprocessing stuff,
> > but with mixed content. ( Common XML ? )
> >
> > API.             I think extremely complex. ( DOM, Xpath e t.c. e
t.c.
> ;-)
> >
> > Mapping       Probably it allows 'convinient' mapping of any data
> structure,
>
> Nice summary.
>
> > The cost of 'convenient mapping' is the complexity of the API.
>
> I think we have the following options:
>
> - Inconvenient mapping, simple API, simple XML syntax (MinXML).
>
> - Convenient mapping, complex API, XML syntax (CommonXML).
>
> - Convenient mapping, simple API, awkward XML syntax
(IndustrialXML).
>
> - Convenient mapping, simple API, non-XML syntax (YML).
>
> That is, convenient mapping costs _something_ - either a more
complex API, a
> more complex syntax, or a break with XML-compatible syntax.
>
> Oren Ben-Kiki

At 09:52 AM 10/5/00 -0400, David Megginson wrote:
>Richard Lanyon writes:
>
> > The question is, how much of the XML-associated technologies do you
> > /need/ in order to be able to start working on XML?
>
>My advice to a new XML user would be to learn XML 1.0 itself, XML
>Namespaces, and (if she's a coder) at least one of the XML-related
>APIs.  A glance at a Unicode tutorial might be a good idea as well.

I'm pushing people toward Common XML core as a foundation:
http://www.simonstl.com/articles/cxmlspec.txt

(Okay, all right, I edited that document, with much help from SML-DEV.)

Now I just need to write a tutorial for Common XML instead of a spec.

One of the things I've really enjoyed about the Common XML work is that
it's refocused me on the core of XML, the parts people really use on a
regular basis, and pulled me away from the delicious 'how do I build
compound element names using parameter entities without introducing a space
in the middle of the name' questions.

Beyond that core of elements, attributes, and simple namespaces, it seems
things really diverge.  Some people want nothing to do with DTDs, planning
to move directly to Schemas (or even RELAX).  Others don't care about
either DTDs or Schemas.  Some folks can get their work done with SAX alone,
while others use just the DOM and others need SAX, DOM, and XSLT working
together, and then maybe they switch to JDOM from DOM and...

Hypertext people need XLink and/or RDF and/or Topic Maps, while programmers
might be more interested in SOAP, XML-RPC, or some other protocol or
messaging work.

The bifurcations are downright incredible - but we can all happily share a
relatively small core.

>After that, she should ignore the other specs until she has a serious
>problem that she cannot easily solve otherwise; if she never ends up
>reading RDF, SMIL, DOM, SAX, XML Schemas, XLink, XPointer, XSLT, SOAP,
>RSS, CSS, XHTML, XHTML modules, etc., then she didn't need them in the
>first place.

Yep.  Giving people a map to the specs they might need someday seems wiser
than teaching them the details.

>On the other hand, if she reads these specs too early, she'll just end
>up inventing problems for the solutions she's learned.  Part of my
>consulting work is cleaning up after people like that.

Mine too, though (because I write largely beginner books) I tend to get
people early enough to tell them not to go ahead instead of cleaning up.
Less lucrative, but it feels good.

>The only so-called XML-related W3C specs my customers have used so far
>in real production systems (as far as I remember) are XML itself,
>Namespaces, RDF (really!), XSLT, and XPointer (only through XSLT,
>though).  I've heard of others using the DOM, though DOM
>implementations seem to run into trouble in high-demand environments.
>In all cases, the customers used each W3C spec because (a) it solved a
>real problem that they would otherwise have had to invent a new
>solution for, and (b) there was available software support.

I'm with David on the reality check, though I see more XHTML (mostly for
the hell of it) and DOM use.  I don't see much XPointer - just XPath.  And
yes, I do see some 'real' RDF work out there.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books

> PS. I think maybe we've made a mistake killing YML.
>
> PPS. When I say "XML" I am already thinking in terms of SAX events /
> nodesets, not in terms of < / > ( there is no < in SAX
> event ;-)

Same here.

> > - Convenient mapping, simple API, non-XML syntax (YML).
> >
> > That is, convenient mapping costs _something_ - either a more
> > complex API, a more complex syntax, or a break with
> > XML-compatible syntax.

What is important:  The information model can
(without too much distortion) handle the XML
information model.  Making our own "native-mode"
syntax isn't that big of a deal as long as we
have reader/writer pairs for XML, and a clearly
defined set of restrictions XML serialized
information must conform to.

I like MinML, but it has the following problem:

   - It doesn't have the concept of a mapping
     which is found in SGML, XML, and relational
     DBMS.  Everything is a list is good, but
     I'm wondering if having the "alternating"
     map/list structure isn't stronger.

This problem prevents round-tripable attributes
for an XML mapping, and also doesn't allow for
a nice mapping to/from relational DBMS.

As for an API, I've looked back at the old ODBC
APIs... and I remember that I'm fond of them.
They are stream-based "pull" interface -- exactly
what Paul was proposing a while ago (when I was
for some stupid reason hung-up on a SAX-like push
stream-based interface).   A stream-based "pull"
interface is also what a XSLT-like processor
requires for efficient processing.

What would you want from such a markup language?

Best,

Clark

----- Original Message -----
From: Clark C. Evans <cce@...>

Long time ;-) Nice to hear from you.

> > PS. I think maybe we've made a mistake killing YML.
> >
> > PPS. When I say "XML" I am already thinking in terms of SAX events /
> > nodesets, not in terms of < / > ( there is no < in SAX
> > event ;-)
>
> Same here.

So let us agree with David Megginson who regards XML as IP layer ;-)
( the same has been said by Bob 100 years ago ;-)

In our case  we can regard SAX events / nodesets as IP / atoms
Then David ( and Bob ) says that we now need TCP / SMTP e t.c.

I think there could be some layer which operates combinations
of atoms.

Let's call that layer TCP.

So SAX is IP
There is TCP ( not designed )
Then there is SMTP ( XSLT, maybe RDF e t.c.)

I'm in big trouble with this TCP layer. It is very fuzzy.
Something like : "if nodeset -> hashtable is true for IP, then
'array of nodesets' ( and 'hashtables of nodesets' ) is TCP".

> > > - Convenient mapping, simple API, non-XML syntax (YML).
> > >
> > > That is, convenient mapping costs _something_ - either a more
> > > complex API, a more complex syntax, or a break with
> > > XML-compatible syntax.
>
> What is important:  The information model can
> (without too much distortion) handle the XML
> information model.  Making our own "native-mode"
> syntax isn't that big of a deal as long as we
> have reader/writer pairs for XML, and a clearly
> defined set of restrictions XML serialized
> information must conform to.

Honestly, I think that the showstopper is

TCP which provides flexible but 'good-for processing'
mappings ". If that's clear - syntax should  come.

The task is darn hard because  working with

  'persistent document'
  'streaming processing'

could/should have the same entities. I think.

> I like MinML, but it has the following problem:
>
>   - It doesn't have the concept of a mapping
>     which is found in SGML, XML, and relational
>     DBMS.  Everything is a list is good, but
>     I'm wondering if having the "alternating"
>     map/list structure isn't stronger.

Well... Right now  I'l say "everything is a hashtable"
is good, but it is not enough. But I have to admit that
this is moving target.

> This problem prevents round-tripable attributes
> for an XML mapping, and also doesn't allow for
> a nice mapping to/from relational DBMS.
>
> As for an API, I've looked back at the old ODBC
> APIs... and I remember that I'm fond of them.
> They are stream-based "pull" interface -- exactly
> what Paul was proposing a while ago (when I was
> for some stupid reason hung-up on a SAX-like push
> stream-based interface).   A stream-based "pull"
> interface is also what a XSLT-like processor
> requires for efficient processing.
>
> What would you want from such a markup language?

I think that the trick is to find entities of TCP which will be
good for processing. Language will come.

If braindumps are still allowed in this list, I may try to find
some time to write a story I got with my 'config files'.
I first wrote it in DOM and then I had to invent 'my' DOM,
which is still moving target and I'm not happy with it, but
it could be a practical illustration to 'what could be that TCP'.

( By the way - remember that 'head/body/role/isa' pattern
long time ago? I feel this also could be related to TCP layer,
but I can not connect the dots. ).

If taking into account that this "TCP" could / should have
some hooks into "DTD" ... oh, my ... 'My' DOM is
already messing with something like 'simplified DTD'
( because I had to provide some roadsigns to SAX handler
how to process the incoming element depending on
it's *future* processing ).

I tend to think that for efficient processing of any data,
roadsigns are unavoidable for almost everything except,
maybe, mixed content.

Rgds.Paul.

> I like MinML, but it has the following problem:
>
>   - It doesn't have the concept of a mapping
>     which is found in SGML, XML, and relational
>     DBMS.  Everything is a list is good, but
>     I'm wondering if having the "alternating"
>     map/list structure isn't stronger.
>
> This problem prevents round-tripable attributes
> for an XML mapping, and also doesn't allow for
> a nice mapping to/from relational DBMS.

MinML doesn't prevent 'layering' mapping concept on
top of it.  I have not found 'map' concept to be
very useful though in my applications.

Best,

Don

Don Park [mailto:donpark@...] wrote:
> > I like MinML, but it has the following problem:
> >
> >   - It doesn't have the concept of a mapping
> >     which is found in SGML, XML, and relational
> >     DBMS.  Everything is a list is good, but
> >     I'm wondering if having the "alternating"
> >     map/list structure isn't stronger.
> >
> > This problem prevents round-tripable attributes
> > for an XML mapping, and also doesn't allow for
> > a nice mapping to/from relational DBMS.
>
> MinML doesn't prevent 'layering' mapping concept on
> top of it.

Sort of. You do encounter problems having both a map and a content for an
element.

> I have not found 'map' concept to be
> very useful though in my applications.

That's a bit strange; don't you ever need something like "element.id",
"item.price" etc.?

Have fun,

	 Oren Ben-Kiki

"Clark C. Evans" wrote:
>

> I like MinML, but it has the following problem:
>
> (...)
>
> They are stream-based "pull" interface -- exactly
> what Paul was proposing a while ago (when I was
> for some stupid reason hung-up on a SAX-like push
> stream-based interface).   A stream-based "pull"
> interface is also what a XSLT-like processor
> requires for efficient processing.

If you are searching for a pull based common
XML parser, take a look at

http://www.kxml.de

Best,
Stefan


--
Stefan Haustein
Univ. Dortmund, FB 4, LS 8   tel: +49 231 755 2499
Baroper Str. 301             fax: +49 231 755 5105
D-44221 Dortmund (Germany)   www-ai.cs.uni-dortmund.de

On Wed, 11 Oct 2000, Oren Ben-Kiki wrote:
> Don Park [mailto:donpark@...] wrote:
> > > I like MinML, but it has the following problem:
> > >
> > >   - It doesn't have the concept of a mapping
> > >     which is found in SGML, XML, and relational
> > >     DBMS.  Everything is a list is good, but
> > >     I'm wondering if having the "alternating"
> > >     map/list structure isn't stronger.
> > >
> > > This problem prevents round-tripable attributes
> > > for an XML mapping, and also doesn't allow for
> > > a nice mapping to/from relational DBMS.
> >
> > MinML doesn't prevent 'layering' mapping concept on
> > top of it.
>
> Sort of. You do encounter problems having both a map and
> a content for an element.

Of course we could represent such a structure
using the MinML syntax, however, MinXML itself
is, IMHO, too weak.

> > I have not found 'map' concept to be
> > very useful though in my applications.
>
> That's a bit strange; don't you ever need
> something like "element.id", "item.price" etc.?

This might be going off the deep end, however,
from set theory, a relation R on a domain A and
codomain B is typically described with the
following properties:

   For each x in A, there exists:
    I)   at least one y in B such that xRy  (is-mandatory)
    II)  at most  one y in B such that xRy  (is-attribute)

   For each y in B, there exists:
    III) at least one x in A such that xRy
    IV)  at most  one x in A such that xRy

If property I&II hold, then R is said to be a
function from A into B.  If, in addition,
property III holds, then R is said to be surjective
(or onto).  If, in addition to I&II, property
IV holds, then R is said to be injective (or 1-1).
If I & II & III & IV hold, then R is said to be
bijective (and the inverse of R is a function).

Anyway, I think if YML is to be successful, it
may must at the veyr least address properties I
and II.  I am unsure if it will need to also
model properties III and IV.  Ideally, the
relevant properties would be exhibited as part
of the syntax.  For example, properties I
and II are loosely related to the map construct,
in particular, a map is a set of relations R with
property II, and a mandatory attribute is a
relation R with property I.  A list is a relation
perhaps with property I, but excluding propety II.

Well, I hope this helps and isn't too far out there.
I am just using this to suggest that since
mathematics frequently use properties I and II in
all but the most trivial of proofs, perhaps our
data modeling language must also manage these
properties.

Best,

Clark

On Wed, 11 Oct 2000, Stefan Haustein wrote:
> If you are searching for a pull based common
> XML parser, take a look at
>
> http://www.kxml.de

Nice; a dramatic improvement over SAX.
Perhaps we should spend some time reviewing
what you have done.  Stefan could you
summarize your approach for us?  I like
what I see and I think it'd be neet if
more attention was focused on this type
of interface.  Perhaps an XML.COM article?
(hint, hint)

The key issue with this type of interface
is how memory is managed (a push interface
all of the memory is on the stack; not so
for this interface).  Since your interface
is Java, this is handled by the garbage
collector.  However, for a C language binding
there would be a lot to talk about...  would
this direction be of interest to the
sml-dev population?

Best,

Clark

"Clark C. Evans" wrote:
>
> The key issue with this type of interface
> is how memory is managed (a push interface
> all of the memory is on the stack; not so
> for this interface).  Since your interface
> is Java, this is handled by the garbage
> collector.  However, for a C language binding
> there would be a lot to talk about...  would
> this direction be of interest to the
> sml-dev population?

Couldn't you use call-by-reference in C
instead of returning event objects?

Best,
Stefan


--
Stefan Haustein
Univ. Dortmund, FB 4, LS 8   tel: +49 231 755 2499
Baroper Str. 301             fax: +49 231 755 5105
D-44221 Dortmund (Germany)   www-ai.cs.uni-dortmund.de

On Wed, 11 Oct 2000, Stefan Haustein wrote:
> > The key issue with this type of interface
> > is how memory is managed (a push interface
> > all of the memory is on the stack; not so
> > for this interface).  Since your interface
> > is Java, this is handled by the garbage
> > collector.  However, for a C language binding
> > there would be a lot to talk about...  would
> > this direction be of interest to the
> > sml-dev population?
>
> Couldn't you use call-by-reference in C
> instead of returning event objects?

Are you suggesting a COM like interface?
(and using the counted pointer pattern?)
This shifts the burden of memory administration
onto the information provider.  Is this
such a good idea?  I was thinking more
along the lines of ODBC like interface
where memory administration weighs a bit
more heavily on the consumer of the data.

Clark

All the things we foretold a year ago are coming to pass ... the complexity of the XML family
of specs is overwhelming the consumers of it (see the trade press       !), the Schema people still haven't
gotten their thing out, and the draft is incomprehensible to all but the most dedicated reader;
 the namespace people spent half the year yelling at each other about what they
REALLY meant, the inconsistencies between the specs with respect to namespaces are causing
serious pain to implementers (right Clark???), ad nauseum.  Furthermore, the W3C leadership seems more
interested in erecting the "semantic web" on top of this morass than in building a solid foundation inside it.

Is it time to outline the "YML" family ... with MinML on the bottom,
something with more built-in capabilities (maybe namespaces, maybe mapping, etc.)
on top of that ... some sense of how one would do transformations, validation, etc...
and push and pull APIs? 

-----Original Message-----
From:   Don Park [SMTP:donpark@...]
Sent:   Wednesday, October 11, 2000 4:22 AM
To:     sml-dev@egroups.com
Subject:        RE: [sml-dev] Re: MinML revisited.

> I like MinML, but it has the following problem:
>
>   - It doesn't have the concept of a mapping
>     which is found in SGML, XML, and relational
>     DBMS.  Everything is a list is good, but
>     I'm wondering if having the "alternating"
>     map/list structure isn't stronger.
>
> This problem prevents round-tripable attributes
> for an XML mapping, and also doesn't allow for
> a nice mapping to/from relational DBMS.

MinML doesn't prevent 'layering' mapping concept on
top of it.  I have not found 'map' concept to be
very useful though in my applications.

Best,

Don




post: sml-dev@eGroups.com

unsubscribe: sml-dev-unsubscribe@eGroups.com

info: http://www.egroups.com/group/sml-dev/info.html

"Clark C. Evans" wrote:
>
> > Couldn't you use call-by-reference in C
> > instead of returning event objects?
>
> Are you suggesting a COM like interface?

I was suggesting using something like

   int kxml_peek_type ();
   int kxml_read_text (char* user_buffer, int max_size);

but for start-tags that would become really ugly...

I am glad that I am using Java and do not need to
think about that kind of questions... :-)

Best,
Stefan


--
Stefan Haustein
Univ. Dortmund, FB 4, LS 8   tel: +49 231 755 2499
Baroper Str. 301             fax: +49 231 755 5105
D-44221 Dortmund (Germany)   www-ai.cs.uni-dortmund.de

"Clark C. Evans" wrote:
>
> Nice; a dramatic improvement over SAX.

thanks :-)

> Perhaps we should spend some time reviewing
> what you have done.  Stefan could you
> summarize your approach for us?

Well, the main difference to push parsers is
that you can ask for the next parse event
when-/whereever you want. There is no need
to implement a set of central event dispatching
callback methods.

Let's assume you want to build an XHTML processor.
With a pull parser, you can write methods
parseBody, parseTable, parseTableRow, ...
and ask the parser for the parsing events where
you need them. You cannot do this with a push
parser. Using a push parser,  you get all events
in central methods. If you receive <tr>, you first
need to look up your current parsing state
from some global (shudder) structure before
you can actually handle the tag. Using
a pull parser, you would implicitly know that
you are in parseTable() and that you can call
parseTableRow now.

Moreover, if Table is an object, you can
implement a constructor that takes a pull
parser as parameter and then constructs
itself from the following events...

Best,
Stefan





--
Stefan Haustein
Univ. Dortmund, FB 4, LS 8   tel: +49 231 755 2499
Baroper Str. 301             fax: +49 231 755 5105
D-44221 Dortmund (Germany)   www-ai.cs.uni-dortmund.de

----- Original Message -----
From: Stefan Haustein <haustein@...>

> you can actually handle the tag. Using
> a pull parser, you would implicitly know that
> you are in parseTable() and that you can call
> parseTableRow now.

... to do that I need to provide parser
with the knowledge of  the schema. Yeah,
with the knowledge of the schema many
cool things could be done.

Rgds.Paul.

On Wed, 11 Oct 2000, Paul Tchistopolskii wrote:
> From: Stefan Haustein <haustein@...>
> > you can actually handle the tag. Using
> > a pull parser, you would implicitly know that
> > you are in parseTable() and that you can call
> > parseTableRow now.
>
> ... to do that I need to provide parser
> with the knowledge of  the schema. Yeah,
> with the knowledge of the schema many
> cool things could be done.

Well, something like Stefan's parser interface
is *exactly* what we should have had a few years
back -- It's a quick win -- what do you all say
that we focus on fine-tuning and documenting
this interface for our

   "pull-oriented stream-based Common XML Parser"

for the next "sml-dev" product?  I'm not trying
to kill YML, but only suggest we also keep a
level of "practicality" in our discussion.
SAX and DOM arn't quite enough.   Stefan, would
you mind us co-opting your interface as a
starting point?  Let's shoot for a Java and
a C binding...  thoughts?  is this a good idea?

Best,

Clark

> Stefan, would
> you mind us co-opting your interface as a
> starting point?

No problem, it's LGPLed anyway...

Best,
Stefan

--
Stefan Haustein
Univ. Dortmund, FB 4, LS 8   tel: +49 231 755 2499
Baroper Str. 301             fax: +49 231 755 5105
D-44221 Dortmund (Germany)   www-ai.cs.uni-dortmund.de