Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: [xml-dev] increment pattern for an attribute..

From: Rick Jelliffe <rjelliffe@-------.---.-->
To: xml-dev@-----.---.---
Date: 11/8/2007 11:23:00 AM
On Thu, 2007-11-08 at 10:12 +0000, Michael Kay wrote:
>  > If you were desparate, you could try the following hack: 
> 
> I think the tag structure is a bit wobbly - but I think I know what you are
> getting at. But it surely violates the XSDL rule that if two element
> particles in a content model have the same name then they must have the same
> type.
 
Doh, I knew that...last month: it came up as an issue with a client's
schema! It is not a problem with UPA but with "Element Declarations
Consistent".  

Of course, RELAX NG can do this kind of thing no problems. I see the new
XSD 1.1 draft has no difference in this regard. 

I've been spending a bit more time using XSD recently, both for the XSD
to Schematron converter project (description and code at XML.COM) and
for an ACORD project. XSD seems to have hit that magical middlepoint
where it is convenient for neither implementers nor users.

XSD is so full of distinctions without (necessary) difference, which
only serve to complicate. Really, what is the need for the language to
have <group> or <attributeGroup> when it could ramp up <complexType> to
fulfill the role (more like RELAX NG patterns)? Why is there a
distinction between derivation by union and choice groups? Why is there
a distinction between derivation by extension and sequence groups?  Why
are substitution groups not explained in terms of choice groups?

And why cannot something be both a string and a number? (i.e. why isn't
some genus of string the simple urtype, since the value-space facets of
the urtype are shonky propositions anyway)  If we can have NaN like
NotANumber why cannot we have NotABoolean and so on? 

Cheers
Rick Jelliffe


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