xml-dev - Re: XML Schemas: Best Practices

[Dan Vint <dvint@slip.net>]

> 
> Hi Folks,
> 
> I would like to move on to the next issue in our schema design list.
> 
> Issue: How do we define the semantics of schema components?
> 
> My initial thoughts on this are that by itself a schema does not define
> the "semantics" of a component.  For example,
> 
> <element name= "jdkdsfjkds">
>     <simpleType>
>         <restriction base= "string">
>             <pattern value= "[a-zA-Z]+\d"/>
>         </restriction>
>    </simpleType>
> </element>
> 
> This is a legal schema declaration for an element, jdkdsfjkds. Now that
> you've seen how jdkdsfjkds is declared, do you understand its
> semantics?  My guess is that you do not.  In one of his messages,
> Richard Lanyon referred to schemas as defining the "syntax" of an
> element and not its semantics.  This makes sense to me.
> 
> Okay, so some questions for you:  
> 
> [1] Do you agree that, by themselves, schemas define just syntax and not
> semantics?


You've shown some of the falicy in the design of most XML applications where
the element names is relied upon to determine those semantics. Things like
Social.Security.Number and Zip.code may have some meaning and semanitcs in the
US, but in other countries they might be as useful as <jdkdsfjkds>.

In most applications that I've seen, you endup relying on the use of an 
appropriate name and maybe the surrounding context (or possibly some attributes)
to provide more meaning. Ulitimatly, the meaning is only captured in whatever
documentation the designer has provided and the context of the user (their
understanding of that documentation).

> 
> [2] A big question ... what is "semantics"?  Is semantics a universal
> thing? Or is it an application-specific thing? That is, is there such a
> thing as the semantics of jdkdsfjkds, regardless of what application is
> using it?  Or, is the semantics of jdkdsfjkds dependent upon the
> application that is using it? (i.e., "in this context jdkdsfjkds means
> xxx, whereas in that context it means yyy")

It seems that is is where some of the scheam features and namespaces were 
brought in to handle these problems. If I have an element <Address> what 
is this? Could be my street address (one line of it, full address, or an
aggregate that spells out the details with other elements) or it could
be the network address of my machine. Context and documentation are the only 
thing that are going to help. 

> 
> [3] 
> <Brainstorming>
>     Can we separate semantics and syntax?  

I think you already showed this to be the situation.

>     Can define the syntax using the XML Schema 
>     language and then apply different semantics, 
>     depending upon the application?

I think you already showed this to be the situation as well.


> 
>     Example. 
>        Application#1: element(jdkdsfjkds) + semantics(A)
>        Application#2: element(jdkdsfjkds) + semantics(B) 
> </Brainstorming>

This is starting to look suspicisously like XML + XSL if you abstract the
meaning you have presented. Some of the semantics implied in a particular
element and its description may be the presentation. For instance, take
123027890, what is this number? If I provide some formatting you might be 
able to tell or make a better guess, $1,230,278.90 or 123-02-7890 now you 
might say money and a social security number.

> 
> [4] How do we "add semantics" to a schema document?

We add semantics with clear documentation and examples and hope that the reader
shares the same framework or context as our description. Which isn't always the
case as I have switched from using SGML in a publishing arena to now using XML
in an Insurance application - names that made sense in publishing now have a 
new context/semantics in the Insurance industry.

> 
> I think that this is a very important and interesting issue.  I eagerly
> await your thoughts on it.  /Roger
> 
> 
..dan