Is <any> really enough for <any><body>?

Tue Jan 11 17:11:30 GMT 2000

Aleksi Niemelä [mailto:aleksi.niemela at cinnober.com] wrote:

> I don't know where to discuss about schemas, I'd like to hear 
> about better place for this discussion.

I don't know any better public forum than xml-dev, but it seems like nobody
wants to get into the nitty-gritty (you know the stuff that makes it
usable).

> How to express some constraints on <any> element? As I see it, 
> specification doesn't provide any ways for this. (Correct me, 
> please!:) 
> 
> What is the right way to express such simple thing as "any element 
> with child X". 
> 

Your examples seem somewhere in the middle between the use cases for
<import>/<include> and <any>.  

With import/include you are aware of some details of the other namespace and
are explicitly saying that specific elements from that namespace can appear
at specific places in content models in this namespace.

With any, you are not aware of the details of the namespace but you are
willing to accept schema-valid elements at specific places in content models
in this namespace.

Your situations seem to be somewhere in the middle where you know enough
information to wildcard, but not enough to include a group.  I'm not sure
how often this middle group would occur to justify enhancements to the any
construct.

In this case, you don't know anything about the namespace other than the
fact that it has elements that apparently contain one of your element's X.
Something like:

<x:tag1>
	<!-- we don't know about y, but allow element by an any content
fragment  -->
	<y:tag2>
	<!-- y knows about us or used an any construct to all x:tag3 to
appear -->
		<x:tag2/>
	</y:tag2>
</x:tag1>

It would of course be directly supportable if you flipped the content model
so it would be:

<x:tag1>
	<x:tag2>
		<y:tag2/>
	</x:tag2>
</x:tag1>

and it avoids an unnecessary shift in namespaces.

> I'd like to reform rule 1 at 3.5 Wildcards (and rest accordingly):
> o Any well-formed XML element item with specified type constraint:
>   any tag, any namespace, any attributes, any content, as long 
>   as it's well-formed and satisfy specified schema's type constraint.
> 
> I can come up with different ways to express same thing:
> <any type='Type'/>
> <element type='Type'/>
> <element name='' type='Type'/>
> 
> But since regular expressions are now introduced, I'd love to use 
> them:
> 
> <element name='*' type='Type'/>
> <element name='*' ref="VaryingName1"/>
> 

I'd like to avoid this, though be tolerable for a validator, it would
complicate schema-aware editors, documentation, etc.  I think that you have
to come down on the side of effectiveness of validation and simplicity of
parser support.  We can always have higher-levels of abstraction and useful
editing shortcuts in our ultimate schema source that we then XSLT to the
schema that the validation uses.  In this case, you could write an XSLT
transform that expands your wildcard element into a choice group.

> Allowing references in the consturct is very important!
> 
> Maybe star wildcard is just enough, but I can make some real use for 
> real patterns too:
> 
> <element name='expect_varying_named_binary_operators'>
>     <element name='(and|or|own.+BinaryOperator)' 
>              type='BinaryOperator'/>
> </element>
> 
> <type name='BinaryOperator'>
>     <element name='*' type='Operand'/>
>     <element name='*' type='Operand'/>
> </type>
> 
> ========
> document_written_by_some_completely_different_user.xml:
> ========
> <expect_varying_named_binary_operators>
>     <own_ultimately_weird_BinaryOperator>
> 	    <op1/>
> 	    <op2/>
>     </own_ultimately_weird_BinaryOperator>
> </expect_varying_named_binary_operators>
> 

This could be cleanly done with something like:

<BinaryOps>
	<BinaryOp>
		<Object class="http://www.xxx.com/myWeirdBinaryOperation"/>
		<Op/>
		<Op/>
	</BinaryOp>
</BinaryOps>

or:

<BinaryOps>
	<BinaryOp operator="xxxns:weirdOperator">
		<Op/>
		<Op/>
	</BinaryOp>
</BinaryOps>

Either of these enforce this structure in this namespace and then allow
alien behavior by little data islands that fit within that structure.
Instead of expecting parts of alien namespaces to adhere to this namespaces
idea of structure.

I think that the current <any> and <anyAttribute> are pretty close to being
able to support the need and their "limitations" cause you to come up with a
better solution.

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 now closed in preparation for transfer to OASIS.