Re: [xml-dev] XML spec and XSD

[Mukul Gandhi <gandhi.mukul@gmail.com>]

Hi Ken,
   Saying that something like, xs:redefine isn't implemented
consistently across different XSD processors, IMHO doesn't justify
condemning XSD completely. I think, even a correct implementation of
say, xs:redefine on one or two processors is good enough. Sometimes,
vendors create differences in implementations to differentiate (I am
not really sure though, if that's true. At least the base standard
should be implementable).

For example, we use different web browsers (IE, Mozilla, Chrome or
whatever) without even caring how well all of these products implement
HTML or JavaScript. We just ignore, minor implementation faults. But
it's also true, that certain vendors take great care to meet the
specifications.

My experience has been, to see that most of the reputable products are
consitent in meeting standards. Some minor differences may happen, due
to the differences in how we interpret the spec, and also the desire
of vendors to differentiate.

As an analogy to this issue, for example I think we all love XSLT 2. I
think, we only have very few XSLT 2 implementations presently. Does
anybody bother to see, if say anything like the XSLT 2 instruction
xsl:for-each-group or any of other XSLT 2 instructions work
consistently across multiple XSLT 2 engines? Dispite for the ignorance
with these issues, people want to program with XSLT 2.

I am not trying to be getting into a mud sludge game between computer
languages, or to express sarcasm to any XML validation language. I
appreciate, efforts of anybody taking pains to design anything like
these languages, and implement them.

On Sun, Nov 15, 2009 at 8:25 AM, G. Ken Holman
<gkholman@cranesoftwrights.com> wrote:
> I wouldn't agree with that.  I also side with Tim and Rick and others who
> grudgingly find they have to work with XSD (usually to meet customer
> requests; personally I migrated from DTD to RELAX-NG and never embraced
> XSD), and for the same reason that Tim cites above: technical issues.  Size
> and complexity are not, necessarily, technical faults.
>
>> From functional point of view, I don't think XSD doesn't work.
>
> There are a number of areas that are problematic.  One example is no two
> vendors have implemented "redefine" the same way.  I had researched this to
> meet specific requirements identified for the UBL project and was burned by
> assuming the way one processor implemented redefine was the way others
> implemented it.
>
>> So many numerous XML applications currently used XSD.
>
> Popularity is no measure of functionality.  Vendors who are pushing XSD
> products would likely tell their clients there are no other choices for
> schema languages.  It is my assessment that vendors and users ignore or are
> unaware of other sources of XML-based technologies, such as ISO/IEC JTC 1/SC
> 34 which created the ISO/IEC 19757 Document Schema Definition Languages
> (DSDL) that includes RELAX-NG, Schematron and NVDL among other XML
> specifications.
>
>> I don't think, there is anything wrong with the basic core/philosophy
>> of XSD.
>
> An example of a core fault is that W3C Schema is not closed under union.  I
> cannot programmatically express the union of two XSD schemas to create a
> third XSD schema that validates instances of the other two.  I might be able
> to by hand, but not programmatically.
>
> This is not academic:  consider an XML document where in two different
> contexts there is an element <x> with different content models.  I then
> write a query that assembles all of the documents <x> elements under a
> single parent result element.  I have to hand-craft the schema that
> validates the result of the query (if it is possible and not an ambiguous
> content model), as I cannot express in XSD-speak two sibling elements with
> different content models.  If I could simply express the union of the two
> original <x> content models as the content model for the query result <x>,
> then I wouldn't have to resort to hand-crafting.
>
> There may be other "core" faults, but that is one that has been a problem
> for me.
>
> In RELAX-NG compact syntax, if I have a grammar "a" and a grammar "b" (be it
> document level, element level or any level of a grammar; at the element
> level both grammars might express different content models for the element
> <x>), the union of these two grammars is expressed as "a | b".  No other
> work is necessary.  An instance of <x> will validate true if it passes the
> constraints expressed by either grammar.
>
>> I guess, some of users who don't like XSD generally, it's
>> probably because of it's huge size, and steep learning curve.
>
> But cognoscenti such as Rick Jelliffe, Tim Bray and many others would not
> find a specification's huge size and steep learning curve a fault if,
> technically, the end result was something that worked well.
>
> It might indeed be a barrier for new people to W3C Schema, but my
> recollection is that negative opinions in this debate have not come from
> representatives of that user group.
>
>> I believe, XSD also get's functionally better with the upcoming 1.1
>> release.
>
> Probably the functionality will be better, yes, but will it address
> everything?  We won't know until it is released, and I suspect some legacy
> 1.0 issues will dog all dot-releases of XSD.
>
> I hope this is considered helpful to the discussion.
>
> . . . . . . . . . . . Ken



-- 
Regards,
Mukul Gandhi