CZ-0001 through CZ-0012 in the Part1 FPDAM proposed disposition documents
MURATA Makoto (FAMILY Given)
eb2m-mrt at asahi-net.or.jp
Thu Jan 7 13:11:19 CET 2010
Now, I have better understanding of your idea, although I do not think
I am able to implement it yet.
> So to conclude. I don't know how schemas for S and T are produced. If
> they are managed as two separate branches I don't see reasons why to
> keep them as much synchronized on component level as possible. Even if
> they are synchronized you can apply simply automated refactoring on them
> to get rid of strange artifacts like union of single type.
The original schemas in 29500:2007 were prepared from a single source,
but the single source is not available to us. I volunteered to
reconstruct such a single source (one of my action items).
> OTOH if both S and T are generated from one "merged" schema then you
> have to add only one simple additional step to turn singleton unions
> into xs:restriction.
But the small step is dedicated to this one particular case, and bunch
of such similar small steps would be needed. My action item will
certainly become more difficult. I would welcome other volunteers.
Is the current design very unreadable? It may look strange if you
consider the strict schema only, but it makes the differences between
S and T very understandable. Frankly, I do not see big advantages in
More information about the sc34wg4