Call for unifying and clarifying XML 1.0, DOM, XPATH, and XML Infoset

[Steven R. Newcomb]

[Henry Thompson:]

> [The XML Schemas draft] certainly
> addresses the question of how a document containing multiple
> namespace-qualified information items can arrange for them to be
> validated by independent, pre-existing schemas for those namespaces.

Exactly how does such validation happen?  For example:

Namespace A's independent schema provides that B elements must contain
a C element and may contain a D element, and that no B may appear
inside a C or a D, and no C or D can appear outside a B.  In other
words (if you'll forgive me for expressing this using traditional DTD
syntax):

 <!ELEMENT A:B ( A:C, A:D?)>
 <!ELEMENT A:C ( #PCDATA)>
 <!ELEMENT A:D ( #PCDATA)>

Namespace F's independent schema provides that G elements may contain
H elements and/or PCDATA, that no G may appear inside an H, and that
no H may appear outside a G.

 <!ELEMENT F:G ( F:H | #PCDATA)* >
 <!ELEMENT F:H ( #PCDATA) >

Now I want to write documents in which, within the constraints
outlined above, I can freely mix A:B, A:C, A:D, F:G, and F:H elements.
In order to make it possible to interchange such documents
meaningfully (in a vendor-neutral, application-neutral etc. context),
I need a way to tell whether my use of each of these namespaces
conforms to its governing constraints.  Following are some questions
that, for whatever reasons, I haven't been able to answer
satisfactorily:

(1) What do I have to do to validate my document against namespace A's
    constraints independently of any validation of namespace F's
    constraints, and vice versa?

(2) If an A:B contains an F:G, I gather that it's OK from the
    perspective of namespace A (right?).  What does
    namespace-A-specific software do with the F:G?  Does it see the
    F:G at all?  If the F:G is hidden, how did it get hidden?  Should
    the A-namespace-specific software look inside the F:G for A:C
    and/or A:D elements?  Is it OK (and/or necessary, from the
    perspective of namespace A's constraints) for A:C and A:D elements
    to be inside the F:G element, or not?

(3) From the perspective of namespace A, what happens to the data
    content of an F:G element that's inside an A:B?  Similarly, what
    happens to the data content of an F:H element that's inside a F:G
    element that's inside an A:C?

(4) Why isn't it possible for an element to be both an A:B and an F:G?
    There seems to be no reason to prohibit this, because it does not
    violate the constraints of either namespace A or F.  There seems
    to be a good reason to allow it; otherwise, one must insert markup
    for an element that serves no purpose other than to accommodate a
    weakness in the XML namespace paradigm.  And, there's no basis for
    deciding, when authoring such a document, whether the A:B should
    be inside the F:G, or vice versa.

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn at techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 517 7954
fax    +1 972 517 4571

Suite 211
7101 Chase Oaks Boulevard 
Plano, Texas 75025 USA

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions and unsubscriptions
are  now ***CLOSED*** in preparation for list transfer to OASIS.