Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@s...> To: <xml-dev@l...> Sent: Sunday, January 20, 2002 11:19 PM Subject: Re: Re: Flexible Schemas (was RE: 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> > >
|
