Names and schemas

[Simon St.Laurent]

[Forwarded for Peter Murray-Rust]

[Steve Newcomb:]

PaulP> I believe that through a careful agreement upon and application of
> definitions, we can get rid of most complaints about the namespaces
> proposal and remove all overlap between that proposal and things
> like architectural forms and XSchemas (under development).

SRN>
>If that's true, then that's GREAT!

>However, I keep stumbling over a problem in my own mind. (Maybe it's
>just too obvious for me to see it.) Using your defined terms, please
>explain the usefulness and/or purpose -- in terms of how it furthers
>the cause of reliable, vendor-neutral information interchange -- of
>declaring that a real or conceptual object exists, in the absence of
>any interchangeable definition of what that object is, or what
>constraints it must conform to in order to be processable.

Here is a simple example of how *I* think that XSchema V1.0 might work. It
is essentially what I have already been doing with my own syntax in
JUMBO1.0 The syntax I use below is clearly up for discussion.

file http://some.where/cml/schema.xml

<?xml version="1.0"?>
<?xml:namespace ns="http://www.w3.org/.../REC-html.html" prefix="HTML"?>
<?xml:namespace ns="http://www.xml.org/xschema.html" prefix="XSC"?>
<?xdev:xschema?>
<XSC:ElementType id="CML:MOL">  <!-- an XSchema declaring a molecule-->
  <XSC:Attribute id="convention">
    <XSC:Type>CDATA</XSC:Type>
    <XSC:Default>#IMPLIED</XSC:Default>
  </XSC:Attribute>
  <XSC:ContentSpec>
    <Seq>#PCDATA</Seq>
  </XSC:ContentSpec>
  <XSC:Link role="behavior" 
    href="http://some.where/cml.MolNode.class"/>
  <XSC:Help><HTML:P>I am a molecule!</HTML:P></XSC:Help>
</XSC:ElementType>

This tells us:
	- there is a beast called <CML:MOL> which we might encounter
	- it might have an attribute 'convention' of type CDATA
	- we can validate its content as PCDATA
	- it is linked to a (specific) Java class 

If we have a document starting like:

<?xml version="1.0"?>
<?xml:namespace ns="http://some.where/cml"
    src="http://some.where/cml/schema.xml"
    prefix="CML">

This says that *any* element starting with CML: belongs to the above
namespace - we all agree, I think. The namespace is defined by the ns field
(we shall soon get an official site for CML :-) That says *who* owns the
namespace - again I think we agree. [This is what the namespace proposal
says].

Now we start getting adventurous. We are allowed to peek inside the file
src="http://some.where/cml/schema.xml 
Clearly we need some semantic conventions to tell us what we have found,
but we are going to have to have those anyway (even if they are archforms,
perl, etc.) I have been very daring and suggested that there is a PI which
tells us this is an XSchema file (we'll have to have something, I assume -
it's a bit hairy to deduce it from the URI). So we agree that this is an
xschema file we have found and that we can read it with an XML parser. I
think we are still agreeing.

Now we have to have some implied semantics, and this is what we are
discussing here. Just as AFs make special use of <? and everyone including
ISO agrees what they mean, we are going to add semantics to elements
beginning <XSC:*. That's all. 

So the semantics I have suggested is that the rule/pattern <XSC:ElementType
id="FOO"> fires whenever an element FOO is found in the document instance.
Thus our application (could be SAX) trundles through the document, skipping 

<!-- lots of irrelevant  XML  -->

until it finds:

  <CML:MOL convention="SMILES">CC(=O)Oc1ccCcc1C(=O))</CML:MOL>

when it records a match. It might simply validate it (in which case a
traditional DTD+parser will do - and it's valid) or it might use the
semantics in MolNode.class. This would read the formula and tell us that we
had a validation error (the 12th character should be 'c' not 'C' assuming
the aspirin molecule was intended). Note that we don't have to add
additional dataTyping here. ***We haven't *typed* it as a molecule***. We
have simply said that we are using a particular algorithm to validate it.

So nowhere have we made large leaps of credibility. I hope I have outlined
the areas where we need to specify our semantics exactly. Of course if we
do not wish to use a preformed algorithm (MOLNode) we have so set those
rules out *in the Xschema*.  I think this is where our main problem lies -
it isn't easy to develop a flexible robust extensible language for this
task within a week. That's why we should leave the actual language
(dataTyping, constraints, etc) to V2.0

[AF Note. From what I've picked up about AFs, I suspect this is similar to
a very simple use where the meta-DTD consists a single element. And I use a
different syntax.]

	P.
 


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)