273810 - Support schema="#mySchema"

Status: RESOLVED FIXED

(Core Graveyard :: XForms, defect)

Description

[Darin Fisher]

Support schema="#mySchema"

Right now, we'll attempt to load baseURI#mySchema, which will load ourselves as
the schema file.  Through the wonders of XTF, that will cause us to get invoked
on the newly loaded XML document, and we'll try to load baseURI#mySchema again.
 As a result, we'll very quickly bloat our memory usage.

We should instead load the schema from the referenced <schema> element when we
encounter a reference fragment.

Comment 1

[Doron Rosenberg (IBM)]

http://lxr.mozilla.org/seamonkey/source/extensions/webservices/public/nsISchemaLoader.idl#52
can be used to load schema from a dom subtree.

Comment 2

[Darin Fisher]

Attachment: v1 patch

OK, this patch includes the following changes:

o  Support more than one space between xsd:anyURI values in the <model>'s
schema attribute.  I made use of nsCStringArray::ParseString for this since
even though that is a bit heavyweight compared to what I could get from custom
parsing code.  I decided to optimize for codesize, so nsCStringArray seemed
like the best choice.

o  When schema documents are parsed inline, we hit IsComplete each time, so we
will generate a bunch of unnecessary rebuild, recalculate, and revalidate
events for each inline schema document.  I initialized mSchemaTotal before
entering the loop to avoid this problem.

o  I used the same technique used by nsXMLEventsManager to extract element IDs
from a xsd:anyURI value.

o  I implemented a XTF element factory for http://www.w3.org/2001/XMLSchema so
that we can call GetElementById to locate <xsd:schema> elements in the
document.  This was a solution that I arrived at after discussing the issue
with bryner and jst.  The problem is that generic XML data elements do not have
an ID attribute, so even if they have an attribute named "id", they cannot be
queried via the DOM getElementById method.  The amount of code required to
implement a XTF factory for XSD that just returns instances of
nsXFormsStubElement is minimal, so this seems like a reasonable solution from a
codesize point-of-view.  I suppose an alternative solution would be to
construct an XPath expression to locate the <xsd:schema> element, but I'm not
sure if that is really worth it considering that this solution is so simple. 
If we ever have a real implementation of schema elements built into mozilla,
then that implementation could override the XTF implementation merely by adding
the XSD namespace to the list in nsNamespaceManager.h.

Comment 3

[Doron Rosenberg (IBM)]

The schema factory will only get called if its inside an XForms document or for
any schema file we load?

Comment 4

[Darin Fisher]

for any schema file we load :(

Comment 5

[Darin Fisher]

Attachment: v2 patch

Here's a version that uses XPath to locate the <xsd:schema> element w/ matching
"id" attribute.  Perhaps this is better afterall... thoughts?

Comment 6

[Doron Rosenberg (IBM)]

I'll test the first patch to see if it breaks anything that uses schema already
(Web Services and my validation code).

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 168268 [details] [diff] [review]
v1 patch

you're missing something in the patch? Or how do you register the XSD
namespace?
And we really should support xsd:schema elements also after xf:model element.

Comment 8

[Darin Fisher]

smaug: you're right... i forgot to include my changes to nsXFormsModule.cpp :(

as for handling <xsd:schema> that appears after the model, that really requires
waiting for the entire document to finish loading.  hmm... so much for
incremental xforms!

Comment 9

[Darin Fisher]

perhaps we could retry loading inline schema after onload if we are not able to
locate the corresponding schema element from the model's doneAddingChildren event.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

not onload, but on DOMContentLoaded. That event is dispatched before 'load' to
document.

Comment 11

[Darin Fisher]

I have a working patch in my tree that uses DOMContentLoaded as suggested.  I
just need to clean it up a bit, and then I'll post it here.  I've decided to go
with the XPath based solution instead of the XTF factory for the XSD namespace.

Comment 12

[Darin Fisher]

Attachment: v3 patch

This version includes the DOMContentLoaded change, plus it also ensures that we
fire xforms-model-construct-done and xforms-ready at the right time.

I built a set of testcases to verify this patch:
http://friedfish.homeip.net/test/xforms/007/1.xml
http://friedfish.homeip.net/test/xforms/007/2.xml
...
http://friedfish.homeip.net/test/xforms/007/10.xml

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 168664 [details] [diff] [review]
v3 patch

>+
>+#ifdef DEBUG
>+  printf("nsXFormsModelElement::OnLoad() schema loaded [%u/%u schema=%p]\n",
>+         mSchemaCount, mSchemaTotal, aSchema);
>+#endif
>+

This adds a new warning to the debug compilation.
nsXFormsModelElement.cpp:494: warning: void format, nsISchema arg (arg 4)

Otherwise looks good.

Comment 14

[Darin Fisher]

The warning comes from GCC, which requires a (void*) cast for parameters that
are pointers of different types.  It seems like a bogus warning to me.

I just removed that printf.  Eventually, I'd like to replace all of the #ifdef
DEBUG printfs in the code with real NSPR logging.