[
Lists Home |
Date Index |
Thread Index
]
If by that you mean that there is a way to drop the antics of document
typing, just by using namespaces, my ears and eyes and mailboxes are wide
open.
I'll try to explain it on my web site, rather on this list (because 95% of
the last mails I popped on this list were wrote by me, so I guess it's time
to calm down a bit), but the short version is : you can't do anything
without an implicit or explicit schema (the operational schema that I
mention in my article). If you plan on using the namespace as a way to
decide what code to run to process some XML data, then you're binding an
abstract schema (the operational schema, which is not written in any given
schema language) to the namespace.
This approach is not a problem at all, it is quite useful indeed. For
example, browsers can render XHTML files with specific content (XHTML+SVG)
by calling the appropriate plugin (eventually obtained by an indirection
through RDDL). However, it means three things :
- that the namespace is de facto providing a type information to each root
element it contains, as a consequence of the association between the
namespace and its various operational schemas.
- that for consistency, schemas should never be allowed to span multiple
namespaces. More precisely, schema for a particuliar namespace could refer
to an element from another namespace, but never go further, i.e. never
attempt to define the internal structure of this external element. If you do
need a schema that completely describes a structure which mixes different
namespaces, surprise, surprise, those various namespace names should be the
same. Namespace cannot have combined semantics, each namespace has its own
semantic that cannot be altered by its the composition of some of its
element names with element names of other namespaces.
- last, that there should be a standard way to compose schemas for different
namespaces. As we cannot expect all namespace to consistently define their
schemas in all the available schema languages, there should be a way to
compose schemas that are written in different languages, e.g. an XML Schema
for the XHTML part and a RELAX NG schema for the SVG part, or a DTD for the
XHTML part and an Schematron schema for the SVG part. This also means that
we have to define a way to resolve namespaces names to a list of schemas,
which RDDL is all about, thus once again making the namespace name the exact
equivalent of a document type as I define it.
Duh... I didn't want to write all this :). Anyway, I'll seriously have to
expand on this because some of my affirmations have to be proven. But the
conclusion of all this is :
- either we don't touch anything, and we consider that namespaces are 50% of
QNames. In that case, we'll have to define the concept of document types,
and solve a lot of related problems.
- or we just say from now that namespaces have an intrisinc meaning, that it
is possible to use them to change the behaviour of programs. In that case
namespaces become a de-facto equivalent of document types, and we'll have to
change a lot of things in schemas, beginning with the isolation of schemas
regarding to namespaces, and the ability to compose them.
Best regards,
Nicolas
http://nicolas.lehuen.com/Articles/Programming/Ideas/fog0000000033.html
----- Original Message -----
From: "Simon St.Laurent" <simonstl@simonstl.com>
To: <xml-dev@lists.xml.org>
Sent: Sunday, January 20, 2002 11:19 PM
Subject: Re: [xml-dev] Re: Flexible Schemas (was RE: [xml-dev] The task tobe
solved by RDDL)
> On Sun, 2002-01-20 at 16:08, Nicolas Lehuen wrote:
> > OK so now I know that we are perfectly in phase on the purpose of RDDL.
So
> > please, please, could you mention in the RDDL specs that RDDL should not
be
> > used as a way to find schemas for a document, because namespaces have
> > nothing to do with document types ? Could we just agree on this, and
then
> > try to move on resolving the bigger problem of associating meta-data to
> > document types ?
>
> Speaking for myself only, I find the notion of "document type" to be a
> mistake in itself, an odd relic of programmers' expectations of
> tightly-controlled data formats. If you find it more useful to
> categorize every acceptable combination of parts from different
> namespaces, you're welcome to do so, of course.
>
> Just keep in mind that a few of us find "the bigger problem of
> associating meta-data to document types" to be much less interesting and
> less useful than "what is this namespace supposed to tell me?"
>
> Guess I'd better get started on the Perversely Oriented Namespace
> Datatyping (POND) project soon.
>
> --
> Simon St.Laurent
> Ring around the content, a pocket full of brackets
> Errors, errors, all fall down!
> http://simonstl.com
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
>
|
