CZ-0001 through CZ-0012 in the Part1 FPDAM proposed disposition documents

Jirka Kosek jirka at kosek.cz
Thu Jan 7 12:47:18 CET 2010


MURATA Makoto (FAMILY Given) wrote:

>> If there is going to be used some automated process for schema
>> generation it can detect unions of single type and automatically turn
>> them into simple restriction. This way there is no burden on maintenance
>> and produced schema doesn't contain excessive constructs which can have
>> unnecessary side-effects.
> 
> I am afraid that I do not quite understand your point.  Could you
> demonstrate your "automated process" using  the strict and transitional
> versions of dml-main.xsd?

Assuming your previous example with merged schema, you can write simple
XSLT transformation for generating Strict as follows:

<!-- By default copy everything -->
<xsl:template match="node()">
  <xsl:copy>
    <xsl:copy-of select="@*"/>
    <xsl:apply-templates/>
  </xsl:copy>
</xsl:template>

<!-- Ignore transitional branches -->
<xsl:template match="when-transitional"/>

<!-- Process strict branches -->
<xsl:template match="when-strict">
  <xsl:apply-templates/>
</xsl:template>

<!-- Refactor unions of single type -->
<xsl:template match="xs:union[not(contains(normalize-space(@memberTypes,
' ')))]">
  <xs:restriction base="{@memberTypes}"/>
</xsl:template>

So in fact, your primary schema sources will contain little bit
different constructs then resulting production use schemas.

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.

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.

I hope that my point is clearer now, if not I will try to elaborate more.

			Jirka

-- 
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka at kosek.cz      http://xmlguru.cz
------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20100107/40c910e0/attachment.pgp>


More information about the sc34wg4 mailing list