[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: painting types
- From: "Bullard, Claude L (Len)" <firstname.lastname@example.org>
- To: "Simon St.Laurent" <email@example.com>, firstname.lastname@example.org
- Date: Tue, 06 Mar 2001 16:03:34 -0600
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
2. Allows one to create new types, such as
the abstract types which are non-instantiable
but name and enable one to choose among
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
XML Schema is complex. It is a sort of
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?
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Simon St.Laurent [mailto:email@example.com]
Sent: Tuesday, March 06, 2001 3:31 PM
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.