RE: painting types

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

Ok.  So please expand on "painting" so 
I get the whole picture.

This seems to be settling down on types.  XML 
schema does at least two things with types:

1.  Allows one to use the 'primitive' types 
of the spec, roughly, the types that a relational 
programmer uses.

2.  Allows one to create new types, such as 
the abstract types which are non-instantiable 
but name and enable one to choose among 
substitution groups.

Of these, the first seems to be sharable among 
all languages and doesn't require a schema if 
they can be added inline, on the other hand, 
that is like archforms:  a privileged set of 
names or attributes and that is just another 
kind of schema.  The second group clearly requires schema.  

1.  The first issue as I understand it 
is that without an infoSet extensive enough 
to be considered a complete data model, there 
isn't enough information to hyperlink reliably 
or perform other common operations (what APIs 
spec by interface).
 
That was the nut of the groves tree as well.  

2.  The second issue is that if alternative 
schema means are used, the data model still 
has to be accounted for by XPath and XSLT. 
The grove guys get another point for the 
grove plans idea.  We need something of that 
sort and that is what Henry says in his 
presentation.

XML Schema is complex.  It is a sort of 
more-than-a-data-object-less-than-an-OOP-object 
spec.  That doesn't bother me much because it 
doesn't actually get into methods and therefore, 
isn't a real OOP.   CSS defined a syntax for 
class/property/selector and that works pretty 
well but isn't XML so ... I found XML Schema 
hard to digest too, but once into it, I found 
it useful.  It answered a lot of questions 
the relational designer next door was asking.  
It also made it possible to match the VRML 
model sensibly (abstract nodes and fields).

Henry has said the draconian parse remains 
inviolate.  XML 1.0 doesn't become more 
complex and anyone who wants to build over 
that can still do so.  So far so good.

The namespace is added to the 
infoset.  We are stuck with namespaces and I 
can live with them.  Ugly, but working and 
I don't have an alternative.  Aggregate docs 
are useful, XPath is working fine even if 
weird to write,  so onward ho

Then come schemas.   So what happens 
to XSLT and XPath (given xml:base, xml:include) 
if there isn't a Schema?  What are the current 
differences among the data models XML Schema helps 
or hinders?  I understand the #FIXED defaults and 
don't need to revisit that.  SGML fixed the process order 
so could do that sensibly.  XML says one doesn't 
have to have the DTD/schema but that introduced the 
dilemma of what to do with post schema validation 
infosets.   If we want to default, we need a common 
means.  XML didn't solve the problem; it punted 
it away for later date.  That day is now.

What precisely happens in XSLT and XPath without 
schemas?  What precisely happens with schemas? 
Its all about properties that are there or not 
there in a data model.  If there are alternatives 
to schemas, how does XSLT and XPath cope without 
knowing in advance what post-process added to 
the nodes in the data model?

Len 
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Simon St.Laurent [mailto:simonstl@simonstl.com]
Sent: Tuesday, March 06, 2001 3:31 PM
To: xml-dev@lists.xml.org
Subject: re: painting types


At 11:50 AM 3/6/2001 -0600, Len Bullard wrote:
>So your first proposal
>to solve the type problem involves using a different
>syntax (not XML parsable, so not XML) to
>create something akin to architectural forms
>thus breaking the tie to XML by tieing it to CSS.

Thanks, Len, but that was just a quick sample of what's possible, not a 
concrete proposal to use CSS syntax for typing. (Note that I specified ad 
hoc, typing over a 7.2bps connection.)

The point is not the syntax, it's the painting.