Re: ANN: Algorithm for Merging a simpleType Dependency Chain

On May 2, 2011, at 2:28 PM, Costello, Roger L. wrote:

> Hey Michael,
> 
>>> I wish to create a single, standalone rendering for BostonAreaSurfaceElevation. 
>>> That is, a representation that does not depend on a base type.
>> 
>> Any particular reason to do that?
> 
> Understanding the constraints on a simpleType is important for understanding an element or attribute of that type.  
> 
> Having a single, standalone representation of a simpleType makes it easier to understand its constraints.


If your goal is just a compact summary of the type's properties,
then producing documentation listing all the effective constraints
on the type (i.e. the contents of its {facets} property) would seem
to address the goal.  In documentation, it is easy to say just
"Values must satisfy all of the following patterns:" and list the
patterns that need to be ANDed together.

If your goal is to generate a single type definition that imposes
all the constraints of the original (so it has the same value and
lexical spaces) and has xsd:anyType or a primitive type as its base
type, then the main flaw in your algorithm is that it does not
always produce such a definition.

I can't tell from the document you pointed to which of these
is your goal.  If it's the first, I'd suggest you use a different notation
instead of using elements in the XSD namespace in non-standard
ways; if it's the second, I think you need to change your algorithm 
to produce simple type definitions that confom to the spec.

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************