Lists Home |
Date Index |
- From: Mark Birbeck <Mark.Birbeck@iedigital.net>
- To: email@example.com
- Date: Wed, 4 Aug 1999 15:19:43 +0100
Paul Prescod wrote:
> Why bother sending any schema information *at all*? If the
> first system
> has the schema and the document, why doesn't it just validate before
> passing the information to the second system?
Because that doesn't validate the transmission, i.e., has everything
been SENT correctly?
> If the second system,
> conversely, can only deal with information that adheres to certain
> rules, then why wouldn't it supply the schema itself. It knows what
> those rules are!
I'm thinking more of flexible, distributed systems. Sure, you could have
the schema already there on the target server, but what happens when it
changes? Or what if the schema is maintained by some third party on a
special 'schema server' so that everyone can be sure they are working to
the same one? I think systems that can 'build' the complete schema from
its components 'as and when' are obviously more flexible.
> Unless I am completely confused, schemas exist to be sent in
> advance to
> be read by humans. These humans use the schemas to build software
> without reams and reams of error checking. Any other use for schemas
> seems to me to be a mere convenience.
I don't agree. Much software will be 'built' on the fly. Editors need
the schema for each document type so that they can determine how a user
can edit that document; data entry tools can use a schema on the fly to
change the user interface as the user moves around a database.
> > Finally, no-one has come back on my point from previous
> emails, that if
> > you want to be able to index and manipulate the massive
> amount of XML
> > data that will exist in coming years, often using
> non-standard schemas,
> > you will need to be able to manipulate the meta-meta-data. And what
> > better tool to use to define this than good old XML?
> XML is not a data manipulation language. What you are really talking
> about are XSL, SAX and the DOM. These can be taught to parse non-XML
> syntaxes. In fact, they already do. XSL and the DOM can parse and
> interpret namespace declarations, for example. SAX will be
> able to soon
> also. XSL and the DOM will soon be able to parse XPaths also.
I didn't say XML was a language of any type, least of all a data
manipulation one. I said that putting the meta-meta-data into a syntax
that was itself XML meant we could use the same tools we use to
manipulate our meta-data to manipulate our schemas, indexes and so on.
So, when two people produce an article with completely different
elements holding the author's name, we can process the schemas which
will in turn allow a search for author to simultaneously check both
I think this issue is very important; everyone is looking forward to the
XML revolution of 'more powerful' searches and all that stuff, yet does
everyone really think that we are going to see conformance across DTDs
and schema as people put their data on the internet? We need to think
about manipulating meta-meta-data if we are to be able to make the most
of these developments.
Perhaps to pose the question more concretely; should there be a
difference between searching for an article written by 'Paul Prescod'
and searching for document types that have an author element? Why
shouldn't I be able to do a search for all articles defined by any
schema that contains an 'author' element, where the value of that
element is 'Paul Prescod'? Should the process of indexing, transmitting,
editing, archiving and so on, be different? Why shouldn't I be able to
convert a schema to French or German using XSL?
So, in the more abstract terms I was using before, should different
tools be used for manipulating meta-data than are used for manipulating
meta-meta-data? Because at the end of the day meta-meta-data is only
meta-data, where 'data' = 'meta-data'.
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)