RE: [legalxml-intjustice] Groups - sentence-order-schema-package.zip uploaded

["Poindexter, Gary" <gary.poindexter@bearingpoint.com>]

Realizing this is a bit off topic:

The document schema imports the extension schema that imports the constraint schema that imports the subset schema that internally uses "ref=" for complex type element definitions. That's five levels of abstraction that a parser has to traverse to ascertain the complete definition of an element based on a complex type (6 or 7 levels if you have an element that uses one of the enumeration schemas). As the complexity of a structure grows, so does the number of times these abstractions are traversed.

Are we (the TC) creating reference schemas that will be used to validate a limited number of instances to test compatibility? If yes, who cares, sorry I brought it up.

If we (the TC) are creating production schemas that we expect people to implement and use to parse hundreds or thousands of instances per day then can someone tell me, in terms that an old assembler programmer will understand, why we need five (or six or seven) levels of abstraction when one would do quite nicely (OK, maybe one more for enumeration schemas)?

Is it reasonable to assume that a reference schema is different (in structure, not in the resulting instances or the final definition of each element) than a production schema?

Do we know if the IJIS testing included a schema without the abstractions vs a schema with the abstractions? Ellen mentioned that they included subset schemas so import of the entire jxdm is not an issue. If not, could we get them to test one? I'll gladly convert any of the schemas to eliminate the abstractions for the test.

gary

-----Original Message-----
From: Scott Came [mailto:scott@justiceintegration.com]
Sent: Thursday, August 26, 2004 2:29 PM
To: legalxml-intjustice@lists.oasis-open.org
Subject: Re: [legalxml-intjustice] Groups -
sentence-order-schema-package.zip uploaded


As promised in the conference call, I've uploaded the partial schema
package to the TC site.

I say "partial", because I have not yet created a sample instance
document, which we agreed should be part of the package.  I should be able
to create that in the next week or so.  I have started one, and taken it
far enough to verify the basic integrity of the schemas and their
relationships.

Nancy Rutter had suggested that I post a summary of the process used to
create the schema package.  Here's the recipe:

1.  Based on the mapping spreadsheet, create a subset package using the
subset schema generation tool.  (Editorial comment:  I found the tool to
be quite nice, fairly easy to use, and stable (I never ran into any killer
bugs, and the load/save and generation functionality worked as
advertised.))  The tool is at
http://gjxdmtools.gtri.gatech.edu/ssgt/subset.

2.  Create a directory named "subset", and unzip the contents of the
zipfile created by the subset tool into this directory.

3.  Use an XSLT transform engine to apply the stylesheet
make-constraint-schema-transform.xsl (included in the package) to the
subset schema (subset/jxdm/3.0/jxdm.xsd) that was unzipped in step 2.
Name the output XML make-constraint-schema.xsl.

In terms of XSLT transform engines...I use Xalan, but any compliant engine
like Saxon or the Microsoft ones should work.  I'd appreciate feedback
from anyone who tries this on an engine other than Xalan.

4.  Edit make-constraint-schema.xsl (created in step 3) to tighten down
cardinality, and to make any other edits to the subset.  The idea is to
save this stylesheet (and update it as needed) for future transformations
on the subset, so that as you create new subsets (e.g., as new
requirements are uncovered, etc.) you don't have to remember all the rules
and reapply them from memory--you just rerun the stylesheet.  If your
subset changes substantially, then you can always regenerate
make-constraint-schema.xsl by rerunning step 3, and start over with new
edits.

(I've included make-constraint-schema.xsl in the package for illustration,
but remember that it gets generated in step 3 and then edited.)

5.  Use an XSLT transform engine to apply stylesheet
make-constraint-schema.xsl (created in step 4) to the subset
(subset/jxdm/3.0/jxdm.xsd) that was unzipped in step 2.  Name the output
XML constraint-schema.xsd.  This is your constraint schema.  You should
not edit this by hand.

(I've included constraint-schema.xsd in the package, but remember it gets
generated, and should not be edited.)

6.  Create extension-schema.xsd.  This has to be created by hand.  It
contains all of your reference-document-specific extensions.  Note how it
will import constraint-schema.xsd, plus any schemas that define any other
namespaces referenced in the extension schema.

7.  Create document-schema.xsd.  This is a very simple schema that simply
identifies an element from constraint-schema.xsd or (more typically)
extension-schema.xsd as the root element of the instance document.  It is
referenced in instance documents using the xsi:schemaLocation attribute on
the root element.  Note how it imports the extension-schema.xsd.

8.  Use the document schema.  You'll probably want to create a sample
instance for illustration purposes.  But a typical "real-world" scenario
for using the document and extension schemas will be to populate the
<types> section of a WSDL document that defines a SOAP web services
message exchange.

And that's about it...hope this is helpful to you all.  Please let me know
if you have questions/comments.

One note about the stylesheet...I believe it adheres to all of the rules
on the subset rules page
(http://justicexml.gtri.gatech.edu/rules_for_schema_subsets.html),
including the cardinality rules and "don'ts" at the bottom.  In
particular, it preserves the order of elements, which is being shown in
performance testing to make a big difference in performance.  It basically
preserves all the structures in the subset generated by the online tool,
but allows you to apply changes in a safe, repeatable, manageable way.

Thanks.
--Scott

> The document sentence-order-schema-package.zip has been submitted by
> Scott Came (scott@justiceintegration.com) to the OASIS LegalXML
> Integrated Justice TC document repository.
>
> Document Description:
> Schema package for sentence order reference document
>
> Download Document:
> http://www.oasis-open.org/apps/org/workgroup/legalxml-intjustice/download.php/8943/sentence-order-schema-package.zip
>
> View Document Details:
> http://www.oasis-open.org/apps/org/workgroup/legalxml-intjustice/document.php?document_id=8943
>
>
> PLEASE NOTE:  If the above links do not work for you, your email
> application may be breaking the link into two pieces.  You may be able
> to copy and paste the entire link address into the address field of your
> web browser.
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/legalxml-intjustice/members/leave_workgroup.php.




To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/legalxml-intjustice/members/leave_workgroup.php.


***************************************************************************************************
The information in this email is confidential and may be legally privileged.  Access to this email by anyone other than the intended addressee is unauthorized.  If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful.  If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************