OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: Issue: redefinitions and order-significance



> http://www.w3.org/TR/xhtml-m12n-schema/

This time I've spent more time to examine it. Apparently, authors didn't
test it with validator. There are tons of

- inclusion points to "../../xyz.xsd" but it is actually at "../xyz.xsd"
- some refers to "img.attlist" but what actually defined is "image.attlist".

 Without any disrespect, I don't think it's appropriate to characterize
XHTML m12n by XML Schema as "modularization". It merely divide the big
schema into smaller pieces. Accidentally this division resembles to
modules, but nothing more.

 There are just too much inter-module dependencies. So my very biased
conclusion is we don't have much to learn from this.




Anyway,

My conclusion is your proposed restriction is too expensive: it's not
worth the merit.



Some techniques that XML Schema uses to implement XHTML m12n is unusable
in TREX.

One is multiple redefinition of the same pattern. For example,

hypertext.xsd:
---------------------
<xsd:attributeGroup name="a.attlist">
    <xsd:attributeGroup ref="Common.attrib" />
    <xsd:attribute name="href" type="URI" />
</xsd:attributeGroup>

events.xsd
--------------------------
<xsd:redefine schemaLocation="hypertext.xsd">
    <xsd:attributeGroup name="a.attlist">
        <xsd:attributeGroup ref="a.attlist" />
        <xsd:attributeGroup ref="a.events.attlist" />
    </xsd:attributeGroup>
</xsd:redefine>

target.xsd
--------------------------
<xsd:redefine schemaLocation="hypertext.xsd">
    <xsd:attributeGroup name="a.attlist">
        <xsd:attributeGroup ref="a.attlist" />
        <xsd:attributeGroup ref="a.target.attlist" />
    </xsd:attributeGroup>
</xsd:redefine>


What happens if both target and events are included from somewhere else?
There is no way to expect those two redefinitions are combined into one.


Related problem is nested/multiple inclusion. XML Schema allows schema A
to include B and C, then B and C in turn includes the same schema D (as
we see in the previous example).

A --+--> B --+
    |        |
    +--> C --+--> D

So validating processors has to somehow identify the same schema. Even
worse, system id cannot be used because these two may reside in the
different directory.

I think we can't allow this in TREX, and without this capability, XHTML
m12n by XML Schema cannot be done.




--
Kohsuke KAWAGUCHI                          +1 650 786 0721
Sun Microsystems                   kohsuke.kawaguchi@eng.sun.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC