Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Defining an XML vocabulary: specify syntax, semantics, and BEHAVIOR?

From: "Costello, Roger L." <costello@-----.--->
To: <xml-dev@-----.---.--->
Date: 4/9/2008 1:17:00 PM
Hi Folks,

Consider a specification of an XML vocabulary.  

   Examples: 
     1. the XSLT specification, 
     2. the XML Schema specification,
     3. the XHTML specification

The specification defines each element.  The definition of each element
will typically include things such as:

   - the syntactic constraints on the contents of the element, e.g. 
     "This element shall be comprised of a decimal value between -90.0
and +90.0"

   - the semantics, e.g.
     "This element shall be used to markup a latitude value."

What about giving instructions to applications that will process the
elements?  

   "Hey application builder, in order for your application to be
compliant, 
    your application must behave in this ____ way when you process 
    element xx, and your application must behave in ____ this way when 
    you process element yy, and so forth"

That is, should the definition of an element also contain "behavioral
instructions?"  


The XSLT, XML Schema, and XHTML specifications go well beyond a
specification of syntactic and semantic information; they contain
behavioral instructions:

1. The XSLT specification, defines the value-of element in this way:

"... the xsl:value-of  instruction can be used to generate computed
text nodes. The xsl:value-of instruction computes the text using an
expression that is specified as the value of the select  attribute, or
by means of contained instructions."

The specification is giving instructions to anyone who wants to
implement an XSLT tool (XSLT processor) on how the tool should behave.

2. The XML Schema specification, defines the "element" element in this
way:

Element declarations provide for:

    * Local *validation* of element information item values using a
type definition

Again, this is instructional information on how the "element" element
should behave.

3. The XHTML specification, defines the p element in this way:

The HTML markup for defining a paragraph is straightforward: the p
element defines a paragraph.

The visual presentation of paragraphs is not so simple. A number of
issues, both stylistic and technical, must be addressed:

    * Treatment of white space
    * Line breaking and word wrapping
    * Justification
    * Hyphenation
    * Written language conventions and text directionality
    * Formatting of paragraphs with respect to surrounding content

Once again, this is an example of a specification going well beyond
syntactic and semantic information; it is providing behavioral
instructions.


Recap: Each of these specifications are specifying for each element in
their XML vocabulary this information:

    1. Syntactic information.
    2. Semantic information.
    3. Behavioral information.


QUESTIONS

1. When defining an XML vocabulary, should behavioral information
always be specified? 

2. Does it make sense to define an XML vocabulary without specifying
behavioral information?

3. Are there two categories of XML vocabularies:

(a) XML vocabularies with behavioral instructions
(b) XML vocabularies without behavioral instructions

As shown above, XSLT, XML Schema, and XHTML are XML vocabularies that
fall in the first category.

Consider a "Book XML vocabulary."  Here's a sample document that
illustrates the Book XML vocabulary:

<?xml version="1.0"?>
<Book>
    <Title>The Wisdom of Crowds</Title>
    <Author>James Surowiecki</Author>
    <Date>2005</Date>
    <ISBN>0-385-72170-6</ISBN>
    <Publisher>Anchor Books</Publisher>
</Book>

Suppose I write a specification for this XML vocabulary.  For each
element I specify its contents and the intended usage.  But suppose
that I don't instruct application developers on the (default and/or
mandatory) behavior of each element.  How will I certify that the
application is compliant?


Thanks!

/Roger


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent