[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-intjustice] Groups - sentence-order-schema-package.zip uploaded
Thanks for the explanation. I have yet to understand the value of global elements in the jxdm; few (or no) element names are used in more than one type definition so the advantage of reuse is non-existent. Eliminating the global element definitions eliminates much of the namespace problem and thus simplifies the entire structure. As long as "(b)" is true, and I agree it probably is in most cases, it doesn't much matter. I just happen to be blessed with a couple "(a)" projects. gary -----Original Message----- From: Scott Came [mailto:scott@justiceintegration.com] Sent: Thursday, August 26, 2004 4:09 PM To: Poindexter, Gary Cc: legalxml-intjustice@lists.oasis-open.org Subject: RE: [legalxml-intjustice] Groups - sentence-order-schema-package.zip uploaded Thanks for the comments, Gary. I'll attempt to answer your questions. First of all, types and elements that are in different namespaces have to be defined in different schemas. No way around that; that's XML Schema. So you're always going to have, at a minimum, two: one for structures specific to the reference document, and one for GJXDM. In our case, we have three, and the chain is this: document imports extension, extension imports constraint, constraint imports proxies. (In terms of namespaces, sentenceOrderDocument uses sentenceOrder uses GJXDM.) Note that your comment that the constraint schema imports the GJXDM schema is incorrect...it does not. The usage of global elements in GJXDM (and reference documents) forces the document to be defined in a separate schema from the other elements, which means it has to be in a separate namespace. The reason is, if you define global elements, then the schema itself does not define what the root element of the instance document is (it could in theory be any of them), so you require a separate schema (and therefore a separate namespace) to force instances to use a particular element for the root. This is one downside to the specification of global elements, but there are upsides as well, so it's not necessarily a criticism. So, bottom line... the combination of (a) well-factored namespaces and (b) global elements in GJXDM, along with the desire to force a particular element to be the root of instances, will always force the document+extension+constraint import chain, plus any additional imports for proxied namespaces (e.g., code enumerations etc.) Note that the chain will only exceed document+extension+constraint due to the proxied namespace imports...the base design will only ever call for document+extension+constraint. Note also that if you have no extensions (rare), you will only need document+constraint. However, I don't believe the chaining is going to matter for most parsing activities, because: (a) Most schema-aware XML parsers like Xerces have optimized schema processing so that by the time the instance is actually processed, the structure against which the instance is validated internally looks like one big monolithic schema, and (b) In real life, I believe it will be rare that software actually performs schema validations on instance messages. In web services scenarios at least, the typical approach is to use the schema in WSDL, then pass the WSDL through a code generation mechanism to generate the message processing code at the endpoints. The performance of that code is going to depend mostly on the serialization mechanism it uses, not on the structure of the schema. In this scenario, the instance stream is not validated against the schema at all...it is deserialized into an object structure. I'll defer to Ellen regarding the IJIS testing and the degree of similarity to how reference documents are evolving. Hope this answers your questions... --Scott > > 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. > *************************************************************************************************** > > 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. ***************************************************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]