Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xml-dev] Restrictions on existence of attributes?

From: Jack Lindsey <Jack@-------.--->
To: xml-dev@-----.---.---
Date: 7/6/2006 12:26:00 AM
Rick:

Vendor attitude and economics are not the only critical factors in going mainstream.  One-stop-shopping in one form or another is a huge selling factor in almost every sector.  It saves time, frustration and usually money.  In IT this typically translates into IDEs or closely knit families of standards like DSDL.  The broader the scope, the greater the user perception of added value, and the greater the likelihood of reaching the critical mass needed to get the implementers beating a path to your door.   

However, I think I am correct in saying that, while Relax NG can import W3C data types, neither it nor any other DSDL module supports inheritance in data structures, i.e. the equivalent of WXS substitution groups with complex type derivation by extension.  This may seem like the ultimate expression of gentrification [1], but I fear that, unless you have any plans for an optional module in this area, that alone could rule you out as a mainstream contender, because these days inheritance seems to be ubiquitous in data modelling of all kinds, call it supertype-subtype, generalization-specialization or class hierarchy, e.g.

- Dave Hay's patterns
- Java-fueled UML everywhere you turn
- Len Silverston's Party Model showing up everywhere, including UMM ebXML Core Components
- the ebXML Registry Information Model itself
- OAGIS extensions
- CPSIN, the Canadian equivalent of the GJXDM [2]

And JAXB or better still XMLBeans can effectively generate Java class hierarchies that exploit the inheritance features of WXS schemas.

Often motivated by the metadata mantra of taxonomy, many organizations are trying to come up with strategies for Enterprise Information Management that encompass all their data resources.  From that perspective, XML is seen as having an important role in bridging the gap between structured and "unstructured" data, i.e. databases and documents, even email.  This means  we will be increasingly working with document content, database content and serialized objects in the same schema or editing session.  So it does not make sense to use two schema languages for most people, now and even less in the future, IMHO (and I have a personal oXygen licence).  We need essentially one language that does it all, modular or otherwise.  

So alternatively, from a user perspective, I strongly support your overtures to the W3C XML Schema WG to integrate Schematron and select features of Relax NG.  That makes so much sense it should be inevitable.  Any feedback on that to date?

Apologies to the diehard bohemians who, if they got this far, are probably hitting the absinthe by now.  But man cannot live by strings and tokens alone and I have to be vigilantly class conscious.  Just getting mainframe DB2 data to Unix box Java programs can provoke unwelcome data type conversions. It is just a fact of life.  However, rather than a member of the gentry, I see myself as more of a shift supervisor at the information factory.  Definitely post-feudal anyway.

Cheers
                  Jack Lindsey, Esq.

--------------------------------------------

[1]  Uche Ogbuji on bohemians, gentry, and Relax NG in 2002

<http://www.adtmag.com/article.aspx?id=6965&amp;page>

and the pitfalls of strong data typing

<http://lists.xml.org/archives/xml-dev/200212/msg00089.html>

[2] Updated guide to CPSIN XML 2-0-0 and visualization tools
    (Not yet available in French)

<http://jack.lindsey.net/DSS/CPSIN XML Guide 2-0-0.pdf>

CPSIN Web site

<http://www.dss-snd.gc.ca/publication/en/chap/splashpage.html>


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