Re: Call for unifying and clarifying XML 1.0, DOM, XPATH, and XML Infos
[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@t... 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@i... 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.
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format