Hello everyone.
Sorry to be 5 years late, but it is just today that I question myself
about derivation by extension and closed world assumption.
Please do not hesitate to comment the following points:
If I define "a" as being a sequence of b,c:
<a>
 <b/>
 <c/>
</a>
and i extend "a" into "aa" that extends that sequence with d:
<aa>
 <b/>
 <c/>
 <d/>
</aa>
then any "aa" will not validate against the definition of "a".
right?
this sounds like a MAJOR difference with OO paradigm (where any "aa" is
also a "a").
that is what i call the closed world assumption in xml validation.
considering i need a more open world approach, i plan
to relax my schema by defining "a" in this way:
<a>
 <b/>
 <c/>
 <xsd:any>
</a>
then i feel like i could extend my "a" definition  without breaking
the "subclass" philosophy.
can anyone comment that point of view?
i am especially interested in possible pitfalls i could have missed in
using the "any" statement.
i am also interested in best practices when defining modular expandable
models.
any help is very welcome.
_______________________________________________________________________
XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe:
xml-dev-unsubscribe@l...
subscribe:
xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
_______________________________________________________________________
XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe:
xml-dev-unsubscribe@l...
subscribe:
xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php