Hi Kohsuke,
> Now, even if you use DOM, it is still possible that you can see
>declarations like:
> <xs:element name="foo" type="diffns:bar"/>
> ... where the schema for "diffns" is undefined. It can appear later in
>the instance document. I'm not 100% sure that this is what you call
>"dangling references". It's related to the section 5.3 of the spec.
Yup, that's it.
> Since I am a bad implementor and I don't know how I can implement such
>an "advanced" feature, I would reject such a "missing component" as
> an error. But I think at least Henry's XSV allows such things.
Evidently we're bad implementors too because we'd also reject it today. :
-) Actually, I think "reject" or "accept" is too coarse a distinction:
this is where assessment outcomes of "unknown" and other such fun PSVI
concepts come in. We're definitely going to build enough info into our
grammars so that we can account for the PSVI; but I'm not all that
confident that once we determine something to be unknown we'll be able to
fill it in later. It would be an interesting feature though.
> When you see a start tag, you use
> 1. the current content model (or the state in the current content model?)
> 2. tag name (uri,local)
> to decide the content model. Right?
That's what we're planning to do in X2. In x1 we have this nasty concept
of "scope" so things are a bit different.
> In RELAX NG, sometimes you cannot determine the content model even if
>you see the whole start tag and its attributes. Like this:
[snip]
> Another problem is, because of this ambiguity, you need to propagate
> information from the child to the parent.
> In DTD or XML Schema, this propagation is unnecessary. So I doubt that
> the interface provides the room for this.
> For example, consider the following schema:
> <choice>
> <group>
> <element name="foo">
> <data type="positiveInteger"/>
> </element>
> <element name="abc"><empty/></element>
> </group>
> <group>
> <element name="foo">
> <data type="negativeInteger"/>
> </element>
> <element name="def"><empty/></element>
> </group>
> </choice>
> Now depending on the value of "foo", the parent has to change its
> behavior.
Yeah that is wild! So you've written a RELAX NG validator; how do you do
this? I'm also curious about how efficient validating with this kind of
grammar is; it looks like it would be even less efficient than XML schema
validation...
But I'm not sure how our current system would account for a content model
like this. I guess we could try and plug some sort of NFA-ish content
model into our scheme; but I'd hate to think about the implementation or
performance characteristics of an approach like that...
> a little more complicated things like "any tag name except xyz:abc" or
>"xyz:*** or abc:def".
This might be ugly but it's not all that hard to see how it could be
grafted on. What sort of approach did you take to constructs like this?
This is a fun discussion; looking forward to your response!
Cheers,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
