RSS MAD

IDtrust Member Section Announces New Steering Committee Members and the

Re: A curiosity? was NVDL: A Disruptive Technology

Dave Pawson wrote:
> Any ideas just why it  generates such a varied response?

This is xml-dev right?

;-)


Cheers,

Manos

Re: A curiosity? was NVDL: A Disruptive Technology

On Tue, May 13, 2008 at 12:45 PM, Dave Pawson
>  Any ideas just why it  generates such a varied response?

anything revolving around schemas with XML seems to do it ;)

ta, Jim Fuller

Re: NVDL: A Disruptive Technology

Michael Kay wrote:
>> This isn't even hard.  XML is a metalanguage.
>>     
>
> An XML schema defines rules for a class of XML documents.
>   
Under that definition, doesn't XSD fail?   It defines rules for a 
namespace not a class of documents.

It has no idea of documents (except for what it tacks on with ID and KEY 
perhaps.)

Cheers
Rick Jelliffe

Re: NVDL: A Disruptive Technology

Since XML Schema can also be used to define rules for XML instances
without a target Namespace I don't think it follows that XSD defines
rules for namespaces, it would be sort of silly to think that a schema
without a target namespace was defining the full allowable grammar of
the empty namespace.

Cheers,
Bryan Rasmussen


On Tue, May 13, 2008 at 10:34 AM, Michael Kay <mike@s...> wrote:
> > > An XML schema defines rules for a class of XML documents.
>  > >
>  > Under that definition, doesn't XSD fail?   It defines rules for a
>  > namespace not a class of documents.
>
>  Well, I wasn't intending it as a rigorous definition, but I think it's
>  defensible.
>
>  I don't know why you think XSD defines rules for a namespace. A (XSD) schema
>  defines rules for a set of named elements and attributes. In the concrete
>  syntax the rules are organized by namespace, but they aren't confined to a
>  single namespace.
>
>  It's true that XSD (intentionally) doesn't treat the document as the primary
>  unit of validation. But it still describes rules for a class of documents,
>  namely those rooted at one of the elements defined in the schema.
>
>  Anyway, I wasn't really talking about XSD or about any schema language in
>  particular. I was just arguing against the thesis that variety is good; in
>  my view it is a necessary evil caused by the inadequacies of the currently
>  available languages, starting with DTDs.
>
>  Michael Kay
>
>
>
>
>
>  _______________________________________________________________________
>
>  XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>  to support XML implementation and development. To minimize
>  spam in the archives, you must subscribe before posting.
>
>  [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>  Or unsubscribe: xml-dev-unsubscribe@l...
>  subscribe: xml-dev-subscribe@l...
>  List archive: http://lists.xml.org/archives/xml-dev/
>  List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>

Re: A curiosity? was NVDL: A Disruptive Technology

I'm really quite intrigued by this thread. Very little has been about 
NVDL (good/bad/indifferent), much about the schema language permathread.

I didn't even see the OP as contentious.

NVDL seems to add another tool to the toolbag. Use it. Ignore it,
pull it out when needed. It works, does what it says on the tin.

Any ideas just why it  generates such a varied response?


regards

-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

[ANN] Axl Library 0.5.1 'La torre de babel' is ready!

          ####################################
          #            Axl Library           #
          #         La torre de babel        # 
          #               0.5.1              #
          ####################################

Advanced Software Production Line is proud to announce a new Axl
Library release.

Axl Library is an small and efficient XML toolkit, written in ANSI C,
and released under the LGPL, that will allow you to produce efficient
and clear code that interfaces with XML data.

The library was produced to support XML requirements needed by
software developed by Advanced Software Production Line, S.L.

At this moment the library is being used by Vortex Library, Af-Arch,
Turbulence, Shaper and Fovap.

Resources
~~~~~~~~~

   Axl Homepage
   [ http://www.aspl.es/xml ]

   Advanced Software Production Line, S.L.
   [ http://www.aspl.es ]

This release in short
~~~~~~~~~~~~~~~~~~~~~

  Next major stable release. Base library (libaxl) was updated to
  allow configuring a set of external handler that allows to perform
  run-time buffered decode operations. This was used to implement
  libaxl-babel, the foundation to give Axl Library support for more
  encoding formats than utf-8.

  Fixed several bugs at the library and some improvements were
  implemented on axl-knife (like producing a C inline representation
  for a DTD). 

Thanks to..
~~~~~~~~~~~
  Benoit Amiaux (report memory leaks on document load failure).
  Dave Dribin (report and fix compilation errors on Mac OS).

Change notifications
~~~~~~~~~~~~~~~~~~~~
  None. 

Changes from previous release 0.4.14
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* [new] Finished support for iso-8859-8 inside axl babel. Updated
  regression test.

* [fix] Updated documentation (new encoding support and some tips to
  check axl build by using regression test).

* [new] Added support for iso-8859-7 into babel and updated regression
  test to check it.

* [fix] Making axl babel to not export encoding header because they
  are only used internally.

* [new] Added support for iso-8859-6 to axl babel. Updated regression
  test to check it.

* [new] Added support for iso-8859-5 encoding inside axl babel.

* [new] Added support to babel for iso-8859-4 encoding.

* [new] Added support for iso-8859-3 encoding format inside axl babel.
  Updated regression test to check this new format supported.  Updated
  documentation.

* [fix] Added initial documentation to explain how to use axl babel
  library.

* [new] Updating axl error module to include a new to produce axlError
  reporting without including axlStream parameter, and allowing
  printf-like arguments. API added:

   - axl_error_report

* [fix] Updated documentation.

* [fix] Renaming libaxl_ns_LDADD and libaxl_babel_LDADD, changing
  LDADD with LIBADD. Error reported by Dave Dribin, while compiling at
  MacOSX.

* [fix] Committing changes to Makefile.am to also export _axl symbols.
  Added missing libaxl-babel.def file.

* [fix] Added explicit references to ../src/libaxl.la object from
  babel/ and ns/ directory.

* [fix] Fixing minor comparison axl_babel_check_utf8_content.

* [fix] Fixing babel bug which wasn't detecting codification for utf-8
  like documents without xml header declaration. Updated regression
  test to reproduce and check the fix introduced.

* [fix] Fixed memory leaks associated to document loading on
  situations where the document is erroneous an its unbalanced at the
  end or the encode detection func fails. Fixes integrated into
  RT. Reported by Benoit Amiaux.

* [fix] Updated regression test to check latest bug found at
  axl_stream_check_content and support to load large utf-8 files
  without content declaration.

* [fix] Fixed bug inside axl_stream_content_check.

* [fix] Making axl stream to not nullify error reference at 
  axl_stream_content_check.

* [fix] Making axl doc module to detect a proper encoding
  configuration and reconfigure document encoding declaration into
  utf-8 to avoid future problems with other APIs like axl_doc_dump*
  functions.

* [fix] Committing changes to compile all the platform..

* [new] Committing changes to produce a pkg-config file for axl-babel
  and updating documentation.

* [new] Updated axl stream engine to allow configuring an external
  handler that allows to check content that goes to the application
  buffer.  This is now used to implement utf-8 checks from
  axl-babel. API added:
   
   - axl_stream_content_check (internal)
   - axl_stream_setup_check
   - axlStreamContentCheck (handler)

* [fix] implemented internal content check for utf-8 files.

* [fix] Updating regression tests..

* [fix] Extended regression test to check wrong utf-8 content.

* [new] Committing support for iso-8859-9 encoding..

* [fix] Updated regression test to check babel support for iso-8859-9.

* [new] Adding files to add support for iso-8859-2 to babel.

* [fix] Committing changes to regression test to check iso-8859-2
support.

* [fix] Adding to babel support for iso-8859-1.

* [fix] Updated regression test to support iso-8859-1 encoding.

* [fix] Updating main configure.ac and Makefile.am file to check and
  build babel. By default enabled as it do not require external
  support.

* [new] Updating regression test to check initial babel features
  (test_41).  Adding documents required by tests.

* [new] Finished initial support to connect a set of handler to
  perform run-time decoding of xml documents opened. GREAT!

* [fix] Updated axl stream API to include new functions to support
  previous feature. API added:

    - axl_stream_link_full
    - axl_stream_decode (internal)

* [new] Committing first fully working implementation of libaxl-babel,
  the component that will provide extended format support to axl base
  library. Added initial support to translate iso-8859-15 content into
  utf-8 as a plug-in to the axl stream decoder support. API added:

    - axlBabelTable (type)
    - axl_babel_init
    - axl_babel_finish
    - axl_babel_detect_codification
    - axl_babel_configure_encoding
    - axl_babel_check_utf8_content
    - axl_babel_build_iso885915_table


* [new] Updated axl stream API to include a function that allows to
  check for the numeric value at the stream header:

    - axl_stream_inspect_code

* [new] Added two new handlers to make codification handling to be
  plug-able and external to the base library. API added:
  
    - axlDocDetectCodification (handler)
    - axlDocConfigureCodification (handler)
    - axl_doc_set_detect_codification_func
    - axl_doc_set_configure_codification_func

* [fix] moving all files to utf-8 codification and committing some
  changes..

* [fix] Committing initial implementation to support codifications
  inside axl. Work in progress.... Updated regression test file to be
  codified using utf-8.

* [new] Added new function to axl stream module that allows to remove
  some particular string on a given string. API added:

    - axl_stream_remove

* [fix] Committing test files to regression test 41.

* [fix] Fixed wrong handling for nodes with only content while dumping
  xml content using pretty functions. Updated regression test to check
  this.

* [fix] Fixed bug at axl_doc_dump* functions which was causing to not
  dump comments included at the root level. Updated regression test to
  check this and the previous bug fix.

* [fix] Making axl_doc_dump* functions to not include new white spaces
  if the comment is found to have starting white spaces (avoid content
  recursion generation).

* [fix] Updated documentation to include some references to axl-knife.

* [new] Added support to the tool to detect if input file is newer
  than output file (--ifnewer) avoiding to recreate it.

* [fix] Fixed bug inside DTD parsing which was causing to not properly
  handle attribute values inside ATTLIST.

* [fix] Fixed wrong handling while calling to axl_stream_get_until_zero
  for streams opened from a file. 

* [fix] Updated axl regression test to produce new dtd inline files
  and to check them for its proper parsing. Nice!!

* [new] axl-knife: Added initial implementation to produce a C inline
  representation from a DTD document, allowing to include the DTD
  inside the code in an easy way.

* [new] Updated axl dtd module API to include a function that allows
  to check if two dtd documents loaded are equal. Updated regression
  test to check this feature.

* [fix] Updated regression test to check support for inline dtd
  support.

* [fix] Added internal check for temporal buffer used inside axl
  stream.

* [fix] Making axl_hash_get to directly return NULL if empty hash is
  detected.

About Advanced Software Production Line, S.L.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  Advanced Software Production Line is leading the Af-Arch project: a
  complete framework to develop distributed application to manage
  enterprise process.

  Af-Arch project uses Axl library to support its XML requirements
  while exchanging data between nodes.

  Advanced Software Production Line also provides GNU/Linux support
  and consulting services to enable organization to introduce
  GNU/Linux inside its process, making other platforms to interact
  with GNU/Linux.

  Contact us, using English or Spanish, to get commercial support
  and/or XML based development services.

  You can reach us:

       http://www.aspl.es - info@a...

  We hope Axl Library help you. Enjoy Axl Library!

--
Francis Brosnan Blázquez           - francis@a...
Advanced Software Production Line  - http://www.aspl.es
12th may 2008, Madrid (Spain)

RE: NVDL: A Disruptive Technology

> > An XML schema defines rules for a class of XML documents.
> >   
> Under that definition, doesn't XSD fail?   It defines rules for a 
> namespace not a class of documents.

Well, I wasn't intending it as a rigorous definition, but I think it's
defensible.

I don't know why you think XSD defines rules for a namespace. A (XSD) schema
defines rules for a set of named elements and attributes. In the concrete
syntax the rules are organized by namespace, but they aren't confined to a
single namespace.

It's true that XSD (intentionally) doesn't treat the document as the primary
unit of validation. But it still describes rules for a class of documents,
namely those rooted at one of the elements defined in the schema.

Anyway, I wasn't really talking about XSD or about any schema language in
particular. I was just arguing against the thesis that variety is good; in
my view it is a necessary evil caused by the inadequacies of the currently
available languages, starting with DTDs.

Michael Kay

[ANN] XSL Tooling 0.5M7

XSL Tooling, an eclipse web tools incubating project, is pleased to 
announce the availability of XSL Tooling 0.5M7.   This is an XSL editor 
and debugger built on top of the eclipse Web Tools project.   New 
features available in this release:

    * New XSL creation wizard.
    * Configurable preferences for validation of XSL.
    * Navigation to definition of called-templates via F3.
    * Smarter XPath validation.

Details can be found in the new and noteworthy document:

http://www.eclipse.org/webtools/development/news/3.0M7/incubator.php

XSL Tooling 0.5M7 can be downloaded at:

http://download.eclipse.org/webtools/downloads/drops/R0.5/S-0.5M7-20080506180143/

Eclipse 3.4M7 and Web Standard Tools 3.0M7 are required as well.

RE: NVDL: A Disruptive Technology

> I was just arguing against the thesis that 
> variety is good; in my view it is a necessary 
> evil caused by the inadequacies of the currently
> available languages, starting with DTDs.

Actually, I don't think that DTDs are inadequate at all.  DTDs fill a
very useful niche.  If all I'm interested in is to define an XML
vocabulary and am not concerned about data type checking (perhaps
because my database is already performing that role), then DTDs are
perfectly fine.  Apparently, other people share this view (of the
adequacy of DTDs); for example, XHTML documents are validated against a
DTD.

Likewise, if I am interested in expressing co-constraints of data
within and across XML documents then all I need is Schematron.  I
certainly don't want to be burdened with the overhead of a
grammar-based language.  Thus, Schematron serves a very useful niche.

"Use the right tool for the right job" is an old adage that seems to be
pretty fundamental.  Just as one programming language is better suited
to a task than another, so too, one schema language is better suited to
a task than another.  Just as variety is rampant and useful in Nature,
variety is rampant and useful in programming languages, schema
languages, and the Web itself!

To summarize, each of the currently available schema languages fill a
niche.  What's needed now is the ability to use them collectively.
More importantly, however, what's needed is for the XML community to
rise to a new abstract level of thought; we need to move away from the
mentality of "using a monolithic schema" to the mentality of "using XML
vocabularies" (wherever they may hail from).  And that's exactly what
NVDL provides.

/Roger

Re: NVDL: A Disruptive Technology???

Melvin Chin wrote:
> Just exactly what does NVDL disrupt?
Yes, I'd agree with that.

What perhaps hasn't come through is that NVDL is just as useful in an 
all-XSD environment as it is in some mixed RELAX NG/Schematron/DTD 
environment.

The issue of how to declare and treat wildcards and of the default 
openness/closedness of schemas has long been discussed in XSD and schema 
circles. Indeed, it has occupied Roger's attention a lot at various time 
as he has been working through issues.

One of the difficulties without NVDL is that at the moment it is the 
developer of the original schema who decides how open that schema is, 
and at what points wildcards or other vocabularies can be used.   If 
their decisions are OK for a particular user, it is fine, but if some 
other user wants to adopt some profile or some particular pattern or 
something that doesn't fit in with derivation by extension (for example) 
or have some kind of interleaving, then they must hack together their 
own schema. But the developers of a vocabulary are the wrong people to 
specify its use: indeed it results in unnecessary attention to 
structures over fields.*

Many people, especially on standards groups, are extremely loath to do 
this, because they are in effect making their own dialect of someone 
else's vocabulary. Some (ODF took this route with SVG) will just use 
their own namespace with the same local names in order to avoid making 
an independent standard.

With NVDL, the decision about how to combine schemas does not depend on 
the schema modules (if that is what the developer chooses) but is 
deferred to a higher level.  The people who make the vocabulary may have 
declared it closed, but the the adopters decide whether to override 
this. And all this without impacting the original schema.

This is validating a view of the data, of course: the idea that elements 
are actually stripped out is not necessary to an implementation.
 

Cheers
Rick Jelliffe

*) 
http://www.oreillynet.com/xml/blog/2007/11/standardize_the_jellybeans_not.html 

Re: NVDL: A Disruptive Technology

Michael Kay wrote:
> All I'm saying is, don't make a virtue out of it. The world would be a
> better place if everyone used the same XML validation language, assuming
> that language met all the requirements (and there's no intrinsic reason why
> one language shouldn't meet all the requirements).
I think those are statements of religious belief (or of worldview) 
rather than of fact. Supporting plurality as the basic property of the 
layered web *is* a virtue. The rejection of monolithic unlayered 
standards is how we got our current progress on the WWW.

>  Having multiple languages
> coexisting just adds cost and complexity, just as mixing programming
> languages in an application adds cost and complexity. No-one wants to do it
> if they can avoid it.
>   
Hmmm, I think this is way too simplistic.

Take SQL and Xpath. Are you saying that an application should not use 
both, if that were the most convenient, because doing so would add cost 
and complexity? If the language is small, targeted and high-level 
enough, it reduces costs and complexity. Does JSON add cost and 
complexity (as a necessary fact, merely because it has alternatives)?  

What will add complexity is multiple monolithic heavyweight languages.  
XSD did almost kill off any advances in schema beyond what it could 
support, because it was so heavyweight, but not quite.  Learning or 
using RELAX NG isn't nearly as complicated as learning XSD.  If the idea 
is to reduce cost and complexity, I am not sure that XSD comes 
particularly low on the list of technologies that you would ditch.

Monolithic languages such as XSD make upgrade, evolution, and 
mix-and-match of vocabularies difficult.

Cheers
Rick Jelliffe

Re: NVDL: A Disruptive Technology

> 
> All I'm saying is, don't make a virtue out of it. The world would be a
> better place if everyone used the same XML validation language, assuming
> that language met all the requirements (and there's no intrinsic reason why
> one language shouldn't meet all the requirements). Having multiple languages
> coexisting just adds cost and complexity, just as mixing programming
> languages in an application adds cost and complexity. No-one wants to do it
> if they can avoid it.

This is exactly what the W3C XML Schema people said to me when I was
there.  I have had a different opinion since then, and have not changed
my mind.  I do not intend to continue religious discussions here.

But let's review the current status of W3C XML Schema.  REALX NG 
can capture co-occurrence constraints between attributes and elements
but W3C XML Schema cannot.  Schematron can capture advanced integrity
constraints but W3C XML Schema 1.0 cannot.  The W3C XML Schema WG
certainly admits this in "Requirements for XML Schema 1.1".  More 
about this, see "2.2.2.1 Add co-constraints (RQ-38)".  Although 
the W3C XML Schema WG has been trying for five years, W3C XML Schema 
1.1 is still a working draft.  This is a strong empirical reason that 
one language does not meet all the requirements.

Cheers,

-- 
MURATA Makoto (FAMILY Given) <EB2M-MRT@a...>

Re: NVDL: A Disruptive Technology

Michael Kay wrote:
>> I'm guessing this requires a level of sophistication more 
>> common on this list (yes, I use multiple schema languages) 
>> than in the world as a whole. This doesn't feel like 
>> something heading toward mainstream.
>>
>> Jonathan
>>     
>
> Quite. I think any instance where users use more than one schema language
> should be taken as evidence of a deficiency in one or more of those
> languages.
>   
Except people make schemas out of pre-existing vocabularies which use 
schema languages out of their control.

How is it a deficiency in XSD that DAISY uses DTDs, for example?

Cheers
Rick Jelliffe

Re: NVDL: A Disruptive Technology

Jonathan Robie wrote:
> I wonder how many users are actually eager to learn more than one 
> schema language, and willing to do so for the benefits one language 
> has over another.
>
> I'm guessing this requires a level of sophistication more common on 
> this list (yes, I use multiple schema languages) than in the world as 
> a whole. This doesn't feel like something heading toward mainstream.
I guess it depends on what you consider mainstream. 

Is ODF mainstream?  They have an issue that some of their vocabularies 
use DTDs, others XSD and others use RELAX NG, for example, which is why 
NVDL might be a good fit for them.  But they use RELAX NG for the main 
schema. Governments are progressively requiring ODF for public 
documents. Already I have seen government projects maintained using 
RELAX NG and converted (jing) to XSD on an as-needs basis.

Is OOXML mainstream? It uses NVDL already. But IS29500 supplies both XSD 
and RELAX NG schemas.

Sometimes it seems that "mainstream" is a euphemism for "can generate 
revenue for big iron makers or toolmakers",  and that certainly has its 
place. (SGML died by being to difficult to make a profit out of; 
Schematron and all DSDL would be much more advanced if any users 
contributed development funding.)  But Schematron is considered 
non-mainstream, yet it is used for handling hundreds of millions of 
financial, taxation and insurance files.  This week I went to teach some 
standards-related courses at our national GeoSpatial organization, and 
they use Schematron as part of their standard set of (XSD) schemas. Is 
mining and mapping mainstream?

The trouble is that  Mainstream != Important, or at least, just because 
something is not "mainstream" does not mean that it is not important.

By the end of this year, most of the world's new documents will be in 
formats described by RELAX NG.  For validation, RELAX NG will be the 
mainstream. I think it is the non-validation uses of schemas where XSD 
will retain its glittering crown for the foreseeable future.

Cheers
Rick Jelliffe

Re: NVDL: A Disruptive Technology???

Just exactly what does NVDL disrupt?

It's a really natural development as schema parsers and validators
become more developed, and its timing is near perfect as we find
more than 1 standardized schema language around.  It's exciting,
but I don't see what market place it disrupts.

For the points you made, (1) is not necessarily a plus point for
users, schema owners, and application developers.  (2) is not
going to be a necessary outcome from presence of NVDL.
(3) is more a "best practice" guideline for schema developers
rather than due to NVDL.  One could always practice writing
simple schemas in a chosen schema language.  A mixed
schema language environment is not an easy one to manage.
(4) is also not a significantly NVDL-only attribute, since
developers still need to worry about proper schema description
and syntax, although they now could pick their own favorite
schema language if their organization permits mix-and-matching
schema languages.  Their focus must still be both vocabulary and
schema.

All in all, I think the excitement about NVDL is understandable.
But I certainly hope its presence is not going to disrupt all
the schema validations and development.

cheers,
mc


At 08:49 PM 11/5/2008, Costello, Roger L. wrote:
>Hi Folks,
>
>Here are the evolutionary (disruptive) changes I envision NVDL bringing
>about in the marketplace:
>
>
>1. Opens the marketplace to utilizing a variety of schema languages.
>
>Previously, you and all your trading partners were locked into using
>one schema language (typically W3C XML Schema) if you wanted
>interoperability.  With NVDL that limitation is lifted and you can
>achieve interoperability while using a variety of schema languages.
>
>
>2. Promotes using the right schema language for the right job.
>
>XML Schema and Relax NG are two schema languages for expressing
>grammar-based rules. They are both standards, the former a W3C
>standard, the later an ISO standard.  Although their capabilities are
>largely overlapping, there are important differences.  "Use the right
>tool for the right job" is an adage that applies to choosing a schema
>language. Knowing the differences in capabilities is important to
>making a good decision in choosing a schema language.
>
>
>3. Encourages the creation of small, simple, independent schemas,
>written in any schema language.
>
>Rick Jelliffe captures this nicely in his article "Standardize The
>Jellybeans Not The Jars"
>http://www.oreillynet.com/xml/blog/2007/11/standardize_the_jellybeans_n
>ot.html
>
>
>4. Moves the application developer's focus from:
>
>        "using a schema"
>
>    to:
>
>        "using XML vocabularies"
>
>
>Can you think of other changes that NVDL may bring about in the
>marketplace?
>
>
>/Roger
>
>_______________________________________________________________________
>
>XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>to support XML implementation and development. To minimize
>spam in the archives, you must subscribe before posting.
>
>[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>Or unsubscribe: xml-dev-unsubscribe@l...
>subscribe: xml-dev-subscribe@l...
>List archive: http://lists.xml.org/archives/xml-dev/
>List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[ANN] SketchPath XPath Tool Refresh

Extending a Complextype - with xsd:all

Hi All,
   I have a complextype already like this
	<xsd:complexType name="MyIdentifier ">
		<xsd:all>
			<xsd:element name="firstname" type="xsd:string"
/>
			<xsd:element name="dateofbirth" type="xsd:date"
/>
		</xsd:all>
		<xsd:attribute name="lastname" type="xsd:string"
use="required" />
	</xsd:complexType>

Is it possible to extend this with xsd:complexcontent and xsd:all. I
have to add 2 more elements, out of which 1 is optional.

Thank you in advance
Regards
Binu K Idicula

Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. 

www.wipro.com

[ANN] oXygen XML Editor and XML Author 9.2

Hello,

A new version of the oXygen XML Editor is available from our website
http://www.oxygenxml.com

oXygen provides a powerful XML development environment supporting all 
schema languages (including the recently discussed NVDL), it offers a 
complete range of development features for XSLT and XQuery (including 
debuggers and profilers) and supports any XML related development.
In the same time oXygen offers a unique combination of visual editing of 
XML documents having out of the box support for DITA, DocBook, TEI and 
XHTML with an advanced text based source editor letting users decide how 
they want to edit their XML data at any moment - stay out of tags in a 
word processor like view or get the power of editing the actual XML code 
directly.

The new version introduces an Author edition that offers special support 
for content authors keeping only the relevant authoring features (no 
interference with the development features). The major additions in 
oXygen 9.2 are related to the WYSIWYG-like editing support and in 
particular to the DITA support. The general visual editing improvements 
include displaying the resolved content in the editor and navigation 
through links. With the new DITA features that include a new DITA map 
editor, an action for inserting conref links, a tight integration with 
the latest version of the DITA Open Toolkit through oXygen's normal 
transformation scenarios mechanism, oXygen becomes the leading DITA 
editor and the easiest to use. Other improvements include browsing of 
XML databases using WebDAV connections, better handling of CJK text, 
support for the Intel® XML Software Suite and multiple component updates.

For a complete list of the new additions and more details please see
http://www.oxygenxml.com/index.html#new-version

Best Regards,
George
--
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com

RE: NVDL: A Disruptive Technology

> This isn't even hard.  XML is a metalanguage.

An XML schema defines rules for a class of XML documents.

A relational schema (create table, create type, etc) defines rules for a
class of SQL databases.

Where exactly do you see the difference?

Michael Kay
http://www.saxonica.com/

RE: NVDL: A Disruptive Technology

> Those are two languages:  SQL and Java.  XML isn't a single language. 

I don't see any difference. SQL, Java, and XML all provide syntax for
describing user-defined data structures and constraints on the instances of
those data structures.

Michael Kay
http://www.saxonica.com/

RE: NVDL: A Disruptive Technology

 
> Mike, that flies in the face of everything we've learned 
> historically and technically about language evolution and 
> separation of concerns in environments where multiple 
> components interface with a complex base.  It's the Big 
> Button strategy.  It has never worked before.  What has 
> changed that would make one believe it can be made to work by remedy?

There aren't two languages for defining integrity constraints in SQL
databases, or for defining assertions in Java; why should there be two for
defining validation constraints in XML documents? The scope is sufficiently
narrow that one language ought to be enough.

Michael Kay
http://www.saxonica.com/

RE: NVDL: A Disruptive Technology

> This is a strong empirical 
> reason that one language does not meet all the requirements.
> 

Certainly no current language meets all the requirements. I'm just saying,
don't pretend that that's an inevitable fact of life let alone a Good Thing.
As far as I'm concerned, it's a situation to be remedied.

Michael Kay
http://www.saxonica.com/

Re: NVDL: A Disruptive Technology

On Mon, May 12, 2008 at 2:24 PM, Costello, Roger L. <costello@m...> wrote:
> > I wonder how many users are actually eager to learn more
>  > than one schema language, and willing to do so for the
>  > benefits one language has over another.
>
>  I know multiple "programming" languages.  Each have their niche.
>
>  Similarly, each of the "schema" languages - XML Schema, Relax NG, DTD,
>  Schematron - have their niche.
>
>  That said, "learning multiple schema languages" is a red herring.  The
>  fact is, people do use different schema languages, for whatever reason.
>  NVDL gives us the ability the abstract away from the particular schema
>  language being used and focus of utilizing the XML vocabularies
>  provided by the schemas.  That, in my opinion, is powerful ... and what
>  makes NVDL a disruptive technology.

I have always thought that the situation we have where no dominant
schema language is probably a good thing over time, instead of a
single general solution we let domain specific schema technologies
(DSC, like DSL but little languages and toolsets for schemas) emerge
... as long as the cost of using these little domain schema languages
is not high then why not (esp if there is an NVDL to facilitate)

u make a good characterisation of NVDL power ... I used to agree with
the 'more is better' mantra; but this goes away when u find out that
there can be situations where 2 schema technologies disagree on
validity and it becomes very hard to do a 'union' of the assertions
that they both positively make .... and who knows what to make of the
negative assertions (usually a manual process).

cheers, Jim Fuller

RE: NVDL: A Disruptive Technology

> 
> I know multiple "programming" languages.  Each have their niche.  
> 
> Similarly, each of the "schema" languages - XML Schema, Relax 
> NG, DTD, Schematron - have their niche.
> 
> That said, "learning multiple schema languages" is a red 
> herring.  The fact is, people do use different schema 
> languages, for whatever reason.


All I'm saying is, don't make a virtue out of it. The world would be a
better place if everyone used the same XML validation language, assuming
that language met all the requirements (and there's no intrinsic reason why
one language shouldn't meet all the requirements). Having multiple languages
coexisting just adds cost and complexity, just as mixing programming
languages in an application adds cost and complexity. No-one wants to do it
if they can avoid it.

Michael Kay
http://www.saxonica.com/

[ANN:] Release 2 of Altova's v2008 product line is available

[ANNOUNCE:] Greetings!

Just a brief note to let you know about Release 2 of Altova's v2008
product line. From very large file support, to new functionality for
working with OOXML and more, a few of the new features are: 

* Very large file support in XMLSpy XML editor
* Support for Java, C#, JavaScript & VBScript in the XSLT engines in
XMLSpy 
* Advanced find & replace in XML Schema editor in XMLSpy
* Support for (integration with and code gen for) Visual Studio 2008 in
XMLSpy 
* Mapping Excel 2007 (OOXML) data to XML, DBs, EDI, etc., in MapForce
* Word 2007 (OOXML)  output from XML and DBs in StyleVision
* BPMN diagrams in UModel
* Diff/merge support for Office 2007 (OOXML) docs in DiffDog
* Global Resources support across multiple tools
* And much more

More details, including screenshots: http://www.altova.com/whatsnew.html
Download an upgrade or free trial: http://www.altova.com/download.html

Re: NVDL: A Disruptive Technology

Len Bullard wrote:
> This isn't even hard.  XML is a metalanguage

Class declaration syntax is also a metalanguage, as is SQL's data 
definition language. People generally consider Java, C++, or SQL to be 
one language each.

Jonathan

Re: NVDL: A Disruptive Technology

Jonathan Robie wrote:
> Of course, these are the same people we recruited for XML by telling 
> them that it's all very simple, showing them how concrete it is, 
> explaining how reading the documents gives you such a good understanding 
> of what's going on. And when we do this, a lot of people conclude that 
> XML is just too hard, that there are 5,184 new technologies you have to 
> master in order to "really" use XML, and that some of these technologies 
> are still being developed.

How long did it take developers to "really" use relational databases?

Is ten years enough?

(I know Fabian Pascal will pop up somewhere to explain that we still 
don't "really" use relational databases properly.)

XML has a simple part that's easily seen on the surface.  It also has 
infinite complexity below the surface - complexity that comes from the 
tasks to which it's applied.

Thanks,
Simon St.Laurent
http://simonstl.com/

Re: NVDL: A Disruptive Technology

G. Ken Holman wrote:
> Hold the phone here ... NVDL is not just for the situation where one 
> finds the semantics available in one schema language preferable over 
> that of the other and they feel obliged to use both.
>
> Rather than writing an über-schema covering all of the possibilities 
> found in a single instance one can use NVDL to choreograph the 
> dispatching of portions of one's document to different schemas using 
> the same schema language for each vocabulary.
>
> I wouldn't want NVDL judged only on its merits of allowing multiple 
> different languages to be used at the same time.  Then it becomes a 
> "mine is better than yours" argument on the languages ignoring what I 
> think is the prime motivation for NVDL:  dispatching ... hence the name!

Yes, this is very helpful.

Jonathan

Re: NVDL: A Disruptive Technology

Costello, Roger L. wrote:
> That said, "learning multiple schema languages" is a red herring.  The
> fact is, people do use different schema languages, for whatever reason.
> NVDL gives us the ability the abstract away from the particular schema
> language being used and focus of utilizing the XML vocabularies
> provided by the schemas.  That, in my opinion, is powerful ... and what
> makes NVDL a disruptive technology.
>   

Yes, this is a real benefit.

I think most people have a favorite schema language which they use most 
of the time. They then exchange data with people who do not use The One 
True Schema Language. We've gotten past the point that we scream at 
those people, we recognize there are advantages to each schema language, 
we just want interoperability. That's a good thing.

Jonathan

RE: NVDL: A Disruptive Technology

Because if all other things are equal, skills and predispositions of the
users aren't.  A single validation presumes a single class of users at a
single level of complexity.  

Validation of the instance per se varies for some definition of validation,
yes?  

len

-----Original Message-----
From: Michael Kay [mailto:mike@s...] 
Sent: Monday, May 12, 2008 11:40 AM
To: Len Bullard; 'Jonathan Robie'
Cc: 'MURATA Makoto (FAMILY Given)'; 'Costello, Roger L.';
xml-dev@l...
Subject: RE:  NVDL: A Disruptive Technology

> This isn't even hard.  XML is a metalanguage.

An XML schema defines rules for a class of XML documents.

A relational schema (create table, create type, etc) defines rules for a
class of SQL databases.

Where exactly do you see the difference?

Michael Kay
http://www.saxonica.com/

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

Re: NVDL: A Disruptive Technology

Kurt Cagle wrote:
> Validation as a concept is generally poorly understood by the 
> aforementioned mainstream. Schematron in particular illustrates that 
> validation does not have to be complete (i.e., all possible assertions 
> that can be made of a given instance are in fact made), and that there 
> really is no such thing as one unique validation for a given XML 
> instance. XSDL tries to take a monolithic approach and succeeds about 
> 75% of the time, but even the XSDL community is recognizing that there 
> are constraints that simply cannot (and should not) be modeled in the 
> language. (I also keep wondering if Kurt Goedel's theorem isn't just 
> waiting in the wings in all of these discussions of (axiomatic?) 
> assertions).

FWIW, I'm a *big* fan of Schematron and of Relax-NG. I've worked on 
schema extensibility myself, as one of the authors of the Schema Adjunct 
Framework, which had some similarities to Schematron.

But this is all pretty abstract to the mainstream. And adding more 
levels of abstraction tends to lose the audience. After explaining 
validation, we then explain the differences between DTDs, Relax-NG, and 
W3C XML Schema, and why there is a compact syntax and an XML syntax for 
Relax-NG. Then we explain Schematron, followed by a reminder that some 
things do wind up being validated in code.

Of course, these are the same people we recruited for XML by telling 
them that it's all very simple, showing them how concrete it is, 
explaining how reading the documents gives you such a good understanding 
of what's going on. And when we do this, a lot of people conclude that 
XML is just too hard, that there are 5,184 new technologies you have to 
master in order to "really" use XML, and that some of these technologies 
are still being developed.

Jonathan

Re: NVDL: A Disruptive Technology

Michael Kay wrote:
>> Those are two languages:  SQL and Java.  XML isn't a single language. 
>>     
>
> I don't see any difference. SQL, Java, and XML all provide syntax for
> describing user-defined data structures and constraints on the instances of
> those data structures.
>   

I agree.

But I'm not sure what the original comment was intended to convey. In 
what way is XML not a single language? There's essentially one markup 
language called XML. Is it not a single language because DTDs, W3C XML 
Schemas, and schemaless docs are all in widespread use, Relax-NG is 
popular with the cool crowd, and Those Who Know rely on Schematron?

You know, a bunch of people I know look at this fragmentation and 
conclude that it's best to do validation at the business level by 
writing code. Creating more schema languages doesn't convince them to 
rely more on schemas and less on code.

Jonathan

RE: NVDL: A Disruptive Technology

> I'm guessing this requires a level of sophistication more 
> common on this list (yes, I use multiple schema languages) 
> than in the world as a whole. This doesn't feel like 
> something heading toward mainstream.
> 
> Jonathan

Quite. I think any instance where users use more than one schema language
should be taken as evidence of a deficiency in one or more of those
languages.

Michael Kay
http://www.saxonica.com/

Re: NVDL: A Disruptive Technology

Michael Kay wrote:
> There aren't two languages for defining integrity constraints in SQL
> databases, or for defining assertions in Java; why should there be two for
> defining validation constraints in XML documents? The scope is sufficiently
> narrow that one language ought to be enough.

Hmm... I don't think I'd ever call the scope of anything in XML 
"narrow", even from a strictly programming perspective.

I marvel at the infinite number of ways people have found to use XML, 
and their ever-changing expectations for how to process it.

Variety is a good thing here.

Thanks,
Simon St.Laurent
http://simonstl.com/

RE: NVDL: A Disruptive Technology

This isn't even hard.  XML is a metalanguage.

I don't disagree about validating in the business logic.

len


From: Jonathan Robie [mailto:jonathan.robie@r...] 

But I'm not sure what the original comment was intended to convey. In 
what way is XML not a single language? There's essentially one markup 
language called XML. Is it not a single language because DTDs, W3C XML 
Schemas, and schemaless docs are all in widespread use, Relax-NG is 
popular with the cool crowd, and Those Who Know rely on Schematron?

You know, a bunch of people I know look at this fragmentation and 
conclude that it's best to do validation at the business level by 
writing code. Creating more schema languages doesn't convince them to 
rely more on schemas and less on code.

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

RE: NVDL: A Disruptive Technology

Those are two languages:  SQL and Java.  XML isn't a single language. 

We've haven't explored the topic of what is expressible in XML application
languages in some time.  How could we narrow that scope relative to the
topic of validation constraints expressible?

Then there are the non-technical but practical issues of utility given
different environments with different classes of users.  The mammal problems
are also a source of complexity.  The language designers are known to say
they can't solve these.  The buyers of the products are known to consider
those problems first.

Mike Daconta and I were discussing this on xml.com.  He used the term
'greedy standard'.  It isn't an aspersion but a way to describe what happens
when one standard tries to fit all requirements and *situations*.

Sorry, I don't want to start a philosophy thread, but it seems to me that
we've never made a single language work in all situations and that is
precisely why we created XML.

len


From: Michael Kay [mailto:mike@s...] 
 
> Mike, that flies in the face of everything we've learned 
> historically and technically about language evolution and 
> separation of concerns in environments where multiple 
> components interface with a complex base.  It's the Big 
> Button strategy.  It has never worked before.  What has 
> changed that would make one believe it can be made to work by remedy?

There aren't two languages for defining integrity constraints in SQL
databases, or for defining assertions in Java; why should there be two for
defining validation constraints in XML documents? The scope is sufficiently
narrow that one language ought to be enough.

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

Re: NVDL: A Disruptive Technology

I'm quite sympathetic to NVDL; having used it to cleanly integrate XHTML and XForms, it's proven to be a real boon just from that standpoint alone, and I suspect that this integration of disparate (albeit complementary in this case) namespaces will continue to be its bread and butter usage for some time.

However, one thing that I have had painful recent experience with is the degree of investment that the status quo (most notably tool vendors) have in XSDL and the sometimes near panicked response made when Relax NG in particular looks like it may threaten that investment. Relax NG and XSDL overlap over a significant aspect of their domain because they are both grammatical validators, though the fairly stubborn rate at which RNG is becoming the alternative not to XSDL but to DTDs makes me suspect that the language has legs its just superior to XSDL for documents, and despite the rise of SOA, document-centric XML is still the dominant usage of the language.

Validation as a concept is generally poorly understood by the aforementioned mainstream. Schematron in particular illustrates that validation does not have to be complete (i.e., all possible assertions that can be made of a given instance are in fact made), and that there really is no such thing as one unique validation for a given XML instance. XSDL tries to take a monolithic approach and succeeds about 75% of the time, but even the XSDL community is recognizing that there are constraints that simply cannot (and should not) be modeled in the language. (I also keep wondering if Kurt Goedel's theorem isn't just waiting in the wings in all of these discussions of (axiomatic?) assertions).

Kurt Cagle
Managing Editor, http://xml.com
kurt@o...

RE: NVDL: A Disruptive Technology

Mike, that flies in the face of everything we've learned historically and
technically about language evolution and separation of concerns in
environments where multiple components interface with a complex base.  It's
the Big Button strategy.  It has never worked before.  What has changed that
would make one believe it can be made to work by remedy?

len


From: Michael Kay [mailto:mike@s...] 
 
> This is a strong empirical 
> reason that one language does not meet all the requirements.

Certainly no current language meets all the requirements. I'm just saying,
don't pretend that that's an inevitable fact of life let alone a Good Thing.
As far as I'm concerned, it's a situation to be remedied.

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

Re: NVDL: A Disruptive Technology

Michael Kay wrote:
>> That said, "learning multiple schema languages" is a red 
>> herring.  The fact is, people do use different schema 
>> languages, for whatever reason.
>  
> All I'm saying is, don't make a virtue out of it. The world would be a
> better place if everyone used the same XML validation language, assuming
> that language met all the requirements (and there's no intrinsic reason why
> one language shouldn't meet all the requirements). Having multiple languages
> coexisting just adds cost and complexity, just as mixing programming
> languages in an application adds cost and complexity. No-one wants to do it
> if they can avoid it.

A lot of people don't like change.

A lot of people don't want to or don't have time to learn new things.

However, if we actually could avoid such issues, I suspect we'd all 
still be programming in COBOL.

COBOL on Cogs, anyone?

http://www.coboloncogs.org/

Before the mess that was W3C XML Schema, I'll confess that I too was 
hoping for "one schema language to rule them all".

Seeing what a catastrophic tangle that yielded, and how RELAX NG and 
Schematron could address different pieces better, made me think that 
despite our laziness, humans can do better having multiple choices in 
processing tools of any kind.  It's a "virtue", even if it does come at 
a cost.

If NVDL can let users make those choices while reducing the confusion 
generated as soon as multiple languages are in use - what gets processed 
by what, and how - then that's a major win for XML users of all kinds, 
even if they never touch NVDL (or realize that they're using it.)

Thanks,
Simon St.Laurent
http://simonstl.com/

RE: NVDL: A Disruptive Technology

> I wonder how many users are actually eager to learn more 
> than one schema language, and willing to do so for the 
> benefits one language has over another.

I know multiple "programming" languages.  Each have their niche.  

Similarly, each of the "schema" languages - XML Schema, Relax NG, DTD,
Schematron - have their niche.

That said, "learning multiple schema languages" is a red herring.  The
fact is, people do use different schema languages, for whatever reason.
NVDL gives us the ability the abstract away from the particular schema
language being used and focus of utilizing the XML vocabularies
provided by the schemas.  That, in my opinion, is powerful ... and what
makes NVDL a disruptive technology.

/Roger

RE: NVDL: A Disruptive Technology

Hold the phone here ... NVDL is not just for the 
situation where one finds the semantics available 
in one schema language preferable over that of 
the other and they feel obliged to use both.

Rather than writing an über-schema covering all 
of the possibilities found in a single instance 
one can use NVDL to choreograph the dispatching 
of portions of one's document to different 
schemas using the same schema language for each vocabulary.

I wouldn't want NVDL judged only on its merits of 
allowing multiple different languages to be used 
at the same time.  Then it becomes a "mine is 
better than yours" argument on the languages 
ignoring what I think is the prime motivation for 
NVDL:  dispatching ... hence the name!

I hope this helps.

. . . . . . . . . . . Ken

At 2008-05-12 12:01 +0100, Michael Kay wrote:
> > I'm guessing this requires a level of sophistication more
> > common on this list (yes, I use multiple schema languages)
> > than in the world as a whole. This doesn't feel like
> > something heading toward mainstream.
> >
> > Jonathan
>
>Quite. I think any instance where users use more than one schema language
>should be taken as evidence of a deficiency in one or more of those
>languages.


--
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and training
G. Ken Holman                 mailto:gkholman@C...
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/x/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/x/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

Re: NVDL: A Disruptive Technology

I wonder how many users are actually eager to learn more than one schema 
language, and willing to do so for the benefits one language has over 
another.

I'm guessing this requires a level of sophistication more common on this 
list (yes, I use multiple schema languages) than in the world as a 
whole. This doesn't feel like something heading toward mainstream.

Jonathan

Costello, Roger L. wrote:
> Hi Folks,
>
> Here are the evolutionary (disruptive) changes I envision NVDL bringing
> about in the marketplace:
>
>
> 1. Opens the marketplace to utilizing a variety of schema languages.  
>
> Previously, you and all your trading partners were locked into using
> one schema language (typically W3C XML Schema) if you wanted
> interoperability.  With NVDL that limitation is lifted and you can
> achieve interoperability while using a variety of schema languages.
>
>
> 2. Promotes using the right schema language for the right job. 
>
> XML Schema and Relax NG are two schema languages for expressing
> grammar-based rules. They are both standards, the former a W3C
> standard, the later an ISO standard.  Although their capabilities are
> largely overlapping, there are important differences.  "Use the right
> tool for the right job" is an adage that applies to choosing a schema
> language. Knowing the differences in capabilities is important to
> making a good decision in choosing a schema language. 
>
>
> 3. Encourages the creation of small, simple, independent schemas,
> written in any schema language.  
>
> Rick Jelliffe captures this nicely in his article "Standardize The
> Jellybeans Not The Jars"
> http://www.oreillynet.com/xml/blog/2007/11/standardize_the_jellybeans_n
> ot.html
>
>
> 4. Moves the application developer's focus from: 
>
>        "using a schema" 
>  
>    to:  
>
>        "using XML vocabularies"
>
>
> Can you think of other changes that NVDL may bring about in the
> marketplace?
>
>
> /Roger
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@l...
> subscribe: xml-dev-subscribe@l...
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>
>   

NVDL: A Disruptive Technology

Hi Folks,

Here are the evolutionary (disruptive) changes I envision NVDL bringing
about in the marketplace:


1. Opens the marketplace to utilizing a variety of schema languages.  

Previously, you and all your trading partners were locked into using
one schema language (typically W3C XML Schema) if you wanted
interoperability.  With NVDL that limitation is lifted and you can
achieve interoperability while using a variety of schema languages.


2. Promotes using the right schema language for the right job. 

XML Schema and Relax NG are two schema languages for expressing
grammar-based rules. They are both standards, the former a W3C
standard, the later an ISO standard.  Although their capabilities are
largely overlapping, there are important differences.  "Use the right
tool for the right job" is an adage that applies to choosing a schema
language. Knowing the differences in capabilities is important to
making a good decision in choosing a schema language. 


3. Encourages the creation of small, simple, independent schemas,
written in any schema language.  

Rick Jelliffe captures this nicely in his article "Standardize The
Jellybeans Not The Jars"
http://www.oreillynet.com/xml/blog/2007/11/standardize_the_jellybeans_n
ot.html


4. Moves the application developer's focus from: 

       "using a schema" 
 
   to:  

       "using XML vocabularies"


Can you think of other changes that NVDL may bring about in the
marketplace?


/Roger

[ANN] DataServices World (June 24, New York City) early bird registratio

DataServices World includes instruction by a world-class faculty, including
speakers from BEA, Blue Cross Blue Shield, DataDirect, IBM, iWay Software,
Microsoft, Morgan Stanley and Sun.

The speakers include an ACM Fellow, Distinguished Engineer and SOA Strategist at
Sun, principal architect of data programmability initiatives at Microsoft, and
other software gurus. They'll be speaking about the data services layer,
scalable database architectures for SOA, heterogeneous data integration, data
modeling, XQuery, WADL and URIs, LINQ and ADO.NET Data Services:

http://www.dataservicesworld.com/events/DSWorld2008/confprogram.htm

Early bird registration closes May 9. To register:
https://www3.sys-con.com/dsw0608/registernew.cfm




======== Ken North ===========
www.KNComputing.com

www.DataServicesWorld.com
www.WebServicesSummit.com
www.SQLSummit.com
www.GridSummit.com

Re: Four things that I've recently learned

Hi Roger,

Costello, Roger L. wrote:
> [...] 
> 
> 4. Multiple validations on the data should be the norm, not the
> exception.
> 
> Also known as "concurrent validation."  Grammar-based validation using
> XML Schema or Relax NG is rarely (if ever) sufficient for checking all
> your data constraints.  Rule-based validation, using Schematron, is
> typically needed for checking co-constraints, cardinality checks, and
> algorithmic checks.  The tandem of a grammar-based validation and
> Schematron validation should be the norm.

DocBook 5 already provides that, it ships with an NVDL script that 
validates against a Relax NG schema and against a Schematron schema.

Best Regards,
George
--
George Cristian Bina
http://www.oxygenxml.com

Re: Four things that I've recently learned

> Hi Folks,
>
> 1. Use the right schema language for the right job.

+1
But I think the interaction between skills, tools, language capabilities
and meeting project objectives is quite complex.

> 2. It's the XML vocabulary that matters, not the particular schema
> language used to implement the vocabulary.

+1
But this is not a statement of principle but a technical goal, actually.

> 3. Create a metaschema that abstracts away the schema language
> implementations, thus enabling applications to focus on processing the
> XML vocabularies, and not worrying about the particular schema
> languages they're implemented in.

+1

And this has impact on standards developers:

http://www.oreillynet.com/xml/blog/2007/11/standardize_the_jellybeans_not.html

> 4. Multiple validations on the data should be the norm, not the
> exception.

+1

Cheers
Rick jelliffe

Four things that I've recently learned

Hi Folks,

1. Use the right schema language for the right job.

2. It's the XML vocabulary that matters, not the particular schema
language used to implement the vocabulary.

3. Create a metaschema that abstracts away the schema language
implementations, thus enabling applications to focus on processing the
XML vocabularies, and not worrying about the particular schema
languages they're implemented in.

4. Multiple validations on the data should be the norm, not the
exception.


For details on each of these, scroll down ...



































1. Use the right schema language for the right job.

XML Schema and Relax NG are two schema languages for expressing
grammar-based rules. They are both standards, the former a W3C
standard, the later an ISO standard.  Although their capabilities are
largely overlapping, there are important differences.  "Use the right
tool for the right job" is an adage that applies to choosing a schema
language. Knowing the differences in capabilities is crucial to making
a good decision in choosing a schema language.





































2. It's the XML vocabulary that matters, not the particular schema
language used to implement it.

What matters is the XML vocabulary, not how it's implemented.

Example: what is important is that you've specified the syntax and
semantics (and possibly behavior) of these elements:

  <Book>, <Title>, <Author>, <Date>, <ISBN>, <Publisher>

It's not important that you've specified the XML vocabulary using XML
Schema, Relax NG, or even DTD.

































3. Create a metaschema that abstracts away the schema language
implementations, thus enabling applications to focus on processing the
XML vocabularies, and not worrying about the particular schema
languages they're implemented in.

Design your data as components that can be assembled, like Lego pieces,
into instance documents, and use NVDL as a metaschema for specifying
the assembled components.



































4. Multiple validations on the data should be the norm, not the
exception.

Also known as "concurrent validation."  Grammar-based validation using
XML Schema or Relax NG is rarely (if ever) sufficient for checking all
your data constraints.  Rule-based validation, using Schematron, is
typically needed for checking co-constraints, cardinality checks, and
algorithmic checks.  The tandem of a grammar-based validation and
Schematron validation should be the norm.

Comments?

/Roger

Re: Requirements on validation: (1) combine schemas, (2) divid

Noah,

> I don't think you've accurately characterised the XSD language.  

Roger quoted what I wrote.

> You can, 
> to a significant degree, to incremenal validation if your validator 
> supports it. 

Here we apparently disagree.  I think that W3C XML Schema fails to 
meet the goal.

>  First of all, you can get a degree of modularity by using 
> facilities like xs:include.

No, xs:include and xs:import merely provides modularization of schemas. 
Modularization is a good thing, but you still have to understand a lot 
about what you want to include or import

I would argue that include/import is simlar to procedure calls 
while NVDL and its precedessors are similar to software components.  

In the case of NVDL, authors of component schemas have to understand 
nothing about the overall picture.  In WXS and RELAX NG, authors have to
understand everything.

You might be interested in my recent note (see my another mail 
"Full validation of Atom feeds containing extensions").  I believe 
that W3C XML Schema cannot capture advanced examples shown in this note.  
RELAX NG probably can do that, but I do not want to maintain such 
complicated schemas.  NVDL and its predecessor NRL provide practical 
solutions.

Cheers,

-- 
MURATA Makoto (FAMILY Given) <EB2M-MRT@a...>

[ANN] Stylus Studio 2008 Release 2 now available

Stylus Studio 2008 Release 2: New EDI support & code generation

[Announce] Dear XML-DEV,

Stylus Studio 2008 Release 2 is now available.The following highlights
some of the new features included in our award-winning XML tools:

* Convert New EDI Formats to XML: Stylus Studio now supports the
Edig@s EDI dialect. With a new Edig@s to XML Schema wizard, as well as
support for the IATA 07.1 revision and numerous other formats
including EANCOM, X12, and HL7, the Stylus Studio product's EDI to XML
conversion tools are among the most comprehensive available today.
* Java and C# for .NET Code Generation: Code generation has numerous
improvements in Stylus Studio, including enhanced support for the
Microsoft .NET processor and new support for the Saxonica Saxon .NET
Processor when generating C# code for .NET. Deploying XQuery, XSLT,
and XML Pipelines across multiple platforms has never been easier.
* Microsoft Visual Studio Project Support: Stylus Studio can
automatically create or update a Microsoft Visual Studio project to
include the C# for .NET class for the XQuery, XSLT, or XML Pipeline
for which you are generating code.
* Enhanced Scalability and Performance: The new release leverages
enhanced optimization techniques including streaming,  to further
improve application performance and scalability when accessing and
converting multiple, large data sources including relational databases
and flat files.
* Support for Standard Java XML Processing API: New support for
industry-standard XML processing APIs in the generated Java code.
* Usability and Performance Enhancements: Various enhancements to the
XML Editor, XQuery Mapper, XML Pipeline Designer, and XML Schema
Editor.

For more information:
Download a free trial at: http://www.stylusstudio.com/xml_download.html
Purchase online at: http://www.stylusstudio.com/buy/

Sincerely,

The Stylus Studio Team
http://www.stylusstudio.com

Full validation of Atom feeds containing extensions

Dear colleagues,

I wrote a note about full validation of Atom feeds containing extensions 
such as OpenSearch and Google Calendar.  Hisashi Miyashita, my
co-author, implemented an NVDL validator for such validaiton.

	Abstract

	The RELAX NG schema in RFC 4287 (The Atom Syndication Format)
	does not provide full validation of Atom feeds containing
	extensions. Rather, this schema skips extension elements and
	attributes, even when extension elements further contain Atom
	feeds or entries. This document shows that ISO/IEC 19757-4
	Namespace-based Validation Dispatching Language (NVDL for short)
	allows full validation of atom feeds containing extensions. NVDL
	decomposes atom feeds containing extensions into (1)
	extension-free atom and (2) extensions so that (1) and (2) are
	validated separately. As an example, an NVDL script for Google
	Calendar is presented. This NVDL script reveals validation
	errors of atom entries embedded in Google Calendar extension
	elements.

This note is available at:

http://www.asahi-net.or.jp/~eb2m-mrt/atomextensions/atomextensions.html

The validator is available at:

http://www.asahi-net.or.jp/~eb2m-mrt/nvdl/SnRNV-1.0.zip


Cheers,

-- 
MURATA Makoto (FAMILY Given) <EB2M-MRT@a...>

Re: Relax NG question: extending an enumeration list?

Costello, Roger L. wrote:
> Hi Folks,
> 
> Is there a way, in Relax NG, to extend an enumeration list?
> 
> For example, here is a schema with an enumeration list:
> 
> --------------------------------------------
> Color.rng
> --------------------------------------------
> <?xml version="1.0" encoding="UTF-8"?>
> <grammar xmlns="http://relaxng.org/ns/structure/1.0">
>     <start>
>         <element name="Color">
>             <ref name="ColorDefn" />
>         </element>
>     </start>
>     <define name="ColorDefn">
>         <choice>
>             <value>white</value>
>             <value>grey</value>
>             <value>blue</value>
>         </choice>
>     </define>
> </grammar>
> 
> I would like to create another schema that imports Color.rng and
> extends its enumeration list.  Here is my (incorrect) attempt:
> 
> --------------------------------------------
> Color-ext.rng
> --------------------------------------------
> <?xml version="1.0" encoding="UTF-8"?>
> <grammar xmlns="http://relaxng.org/ns/structure/1.0">
> 
>     <include href="Color.rng" />
> 
>     <define name="ColorDefn" combine="interleave">
>         <choice>
>             <value>green</value>
>             <value>purple</value>
>         </choice>
>     </define>
> </grammar>
> 
> What is the correct way of doing it (if it's possible)?  <define name="Month">
     <a:documentation>
       <html:p>Element </html:p>
     </a:documentation>
     <choice>
       <value>Jan</value>
       <value>Feb</value>
       <value>Mar</value>
       <value>Apr</value>
       <value>May</value>
       <value>Jun</value>
       <value>Jul</value>
       <value>Aug</value>
       <value>Sep</value>
       <value>Oct</value>
       <value>Nov</value>
       <value>Dec</value>
     </choice>
   </define>


Is my 'exampler'

HTH


regards

-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

[ANN] EditiX XML Editor 2008 - SP3