Re: Finding root element..

I think you're about right.  The "nesting" (which is called local scoping) 
actually allows the same name to be used with different types in different 
scopes.  You can see why it's hard to start a validation from such a 
point, becuase you'd have to trust that the containing element was indeed 
the right one to establish the scope.  So, preventing validation of locals 
wasn't a goal, but you're correct that it is a byproduct of the design. We 
considered having a root marker, but then we would have needed a switch to 
disable it when you were doing incremental validations anyway.  We choose 
to just leave it out, but that does mean that we rely on the environment 
to establish legal roots.  Thanks!

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Kevin Hanna <kevin@hanna.net>
02/21/2003 10:08 PM

 
        To:     Noah Mendelsohn/Cambridge/IBM <noah_mendelsohn@us.ibm.com>
        cc:     xmlschema-dev@w3.org
        Subject:        Re: Finding root element..


Thanks,  in reading your reply I think I finally clued in to how my 
current of thought was wrong.

The problem I'm facing is most schemas I look at use refences rather 
than nesting elements to make the XSD _more readable_.  Looking at so 
many like this I ASSumed it was the right way to do it.  But I guess if 
you don't want <b>  (in your second example) to be a valid root element 
in an instance document then you *have* to nest it rather than use a 
reference.

If I'm right; If you want the ability to validate fragments you are 
losing the ability to ensure a document is complete (like you might want 
in XHTML where the root element has to be 'html'), but if you nest all 
the xs:elements rather than using references you are losing the ability 
to validate fragments (like you might want to do with a 'table' you are 
about to insert in to an XHTML doc).

Maybe XML Schema could use  a root qualifier in order to define a root 
element thus allowing you to determine if some XML is a valid document, 
valid fragment or invalid.  Or did I miss the boat again? ;)

Thanks for your reply,
Kevin

Noah Mendelsohn/Cambridge/IBM wrote:

>Kevin Hanna asks:
>
> 
>
>>>Has anybody come up with a fail proof way to 
>>>find the root element in *any* XSD?
>>> 
>>>
>
>Well, for better or worse, that's not quite how xml schema works.
>
>The following schema, is just fine:
>
><xsd:element name="a"/>
><xsd:element name="b"/>
>
>It will potentially evaluate:
>
>doc1:
>
>        <a/>
>
>- and - 
>
>doc2:
>
>        <b/>
>
>Now we can make it fancier:
>
>
><xsd:element name="a">
>        <xsd:complexType>
>                <xsd:sequence>
>                        <element ref="b"/>
>                </xsd:sequence>
>        </xsd:complexType>
></xsd:element>
><xsd:element name="b"/>
>
>Ah, you say, now surely "a" is the root?  Not necessarily.  This schema 
>will validate:
>
>
>doc1:
>
>        <a>
>                <b/>
>        </a>
>
>- and - 
>
>doc2:
>
>        <b/>
>
>Bottom line:  any global element can serve as the root of a validation, 
>whether or not that element is used as another's content.
>
>I'm sure you're going to ask:  why?  Well, among the reasons is that 
>schema is designed to support validation of fragements, free-standing 
>elements, etc.  We don't necessarily distinguish the free standing "b" in 

>doc 2 from the nested one in doc 1.  You can validate either one on its 
>own, presuming your processor is written to let you start with a nested 
>element.  Also:  there are vocabularies in which it's handy to define one 

>whole namespace in a single schema document, but in which the voculary 
>supports two different types of document (request and response, perhaps). 

>
>Anyway, that's how it works.  (By the way, I somewhat simplified the 
>explanation of the examples.  The elements declared without explicit type 

>are implictly of anytype, and each of them could have allowed children, 
>which I didn't show.)
>
>------------------------------------------------------------------
>Noah Mendelsohn                              Voice: 1-617-693-4036
>IBM Corporation                                Fax: 1-617-693-8676
>One Rogers Street
>Cambridge, MA 02142
>------------------------------------------------------------------
>
>
>
> 
>

Received on Friday, 21 February 2003 23:21:28 UTC