[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] SBS and Restricted Data Types
Please see additional comments/clarifications below marked with [JMC]. I also clarify one of your questions to Ken (Ken will of course correct me if I am wrong). Joe Kind Regards, Joseph Chiusano Associate Booz Allen Hamilton 700 13th St. NW, Suite 1100 Washington, DC 20005 O: 202-508-6514 C: 202-251-0731 Visit us online@ http://www.boozallen.com -----Original Message----- From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk] Sent: Wednesday, May 03, 2006 1:32 PM To: ubl-dev@lists.oasis-open.org Subject: RE: [ubl-dev] SBS and Restricted Data Types Thanks for this Joe, > > Just so we're clear on terminology regarding the two primary files we > are talking about: > > - When we refer to a "subset definition", we mean the the file whose > contents are XML (not XPath), even though there is "XPath" in the file > name. The following file would be an example of what you call a > "subset > definition": > http://docs.oasis-open.org/ubl/cs-UBL-1.0-SBS-1.0/xpaths/xml/XPath/Des > pa > tchAdvice-XPath.xml. Yes, this is a kind of implementation of the XPaths methodology although (Ken's help needed here) the file doesn't have XPaths expressions in it. It is optimised though to allow expressions of XPaths to be generated. It has extra info not allowed just in such expressions, particularly cardinalities. > > - When we refer to an "XPath file", we mean the file whose contents > include the XPath expressions (plus other items in the leftmost > columns, such as cardinality constraints). The following file would be > an example of what we call an "XPath file": > http://docs.oasis-open.org/ubl/cs-UBL-1.0-SBS-1.0/xpaths/text/Despatch > Ad > vice-XPath.txt > (though at the top it is labeled as an "XPath information file") > > Is that correct so far? No. [JMC] Ok - but this perplexes me as I have seen this type of file consistently referred to as an "XPath file" on this list. If that is not the proper term for this file, what is? The files containing XPaths expressions in various formats are only for convenience.I think we might want to consider in UBL 2 dropping the term XPaths file and just refering to subset definition files (or perhaps call them SBS files if appropriate). The first files above are normative to the SBS and include cardinality information as well as (though not needed for UBL) text attributes to allow for mixed content (not allowed in UBL). Is that correct Ken? [JMC] <PlayingTheRoleOfKen>Actually the "second files" (being careful not to mix terminology) do contain cardinality information, just to the left of each XPath expression (e.g. 0..1)</PlayingTheRoleOfKen> Not sure if that changes anything for our discussion and for the consideration you mentioned above (potentially not referring to the "second file" above within UBL 2.0, just the "first file" above). [end of comments] Thanks, Joe > > Also, what do we mean when we refer to an "XPath XML file"? The first > type of file above, or the second? The first, the subset definition files. > > Perhaps it might be good to standardize on terminology:) Point taken. Thanks All the best Steve > > Thanks, > Joe > > Joseph Chiusano > Associate > Booz Allen Hamilton > > 700 13th St. NW, Suite 1100 > Washington, DC 20005 > O: 202-508-6514 > C: 202-251-0731 > Visit us online@ http://www.boozallen.com > > -----Original Message----- > From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk] > Sent: Wednesday, May 03, 2006 7:57 AM > To: ubl-dev@lists.oasis-open.org > Subject: RE: [ubl-dev] SBS and Restricted Data Types > > Hi Martin, > > Excellent question. Simply put I'd say you hand the subset definition > to a developer and ask him/her to produce a Schematron schema or just > write code (such as Java or C++ or perhaps Python or Perl or VB/C# or > even shell script or DOS, whatever) but there might best be a way to > allow both parties in the transaction to use the exact same validation. > That suggests a Schematron schema being a good output of the UBL TC as > is being done for codelists. We'll see how things develope for UBL 2. > > Another point: although the codelist methodology suggests a 'second > pass' > validation - using first XSD for the first pass and the Schematron for > a second (which depends on the success of the first for accuracy), I'd > suggest it be not just 'two pass' but 'two phase' to allow several > passes in the second phase (Schematron or equivalent for codelists, > subsets and business rules, not necessarily in that order). > Alternatively, since I believe (put me right if I'm wrong) there is an > import or include mechanism in Schematron, I wonder whether one might > not just have a single Schematron logical schema comprised of modules > for codelists, subsets and business rules that can all be used at once. > The first option, perhaps with pipes of some kind, could be the more > appropriate. But if onl;y two passes are allowed then the second could > perhaps do the trick. Furthermore there is a possibility that there > may be more than one subset per message; one public like the SBS and > another more private or specialised for trading partnerships, > marketplaces, etc > - which is a strict restriction (in XSD logic) of the first subset > which is in turn a strict restriction of the schema of which the > instance namespace is derived (which could be a customisation - > restriction/and or extension - of UBL, say). > > All the best > > Steve > > > > > > Quoting Martin Forsberg <martin.forsberg@amnis.se>: > >> Hi Stephen, >> >> Could you give an example of how to use the xpath-files when actually >> validating the document instance? Is it possible to validate that the >> sender follows the subset and make sure that he sends only what we >> have agreed upon (and no more). >> >> Regards >> Martin Forsberg >> >> -----Original Message----- >> From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk] >> Sent: den 3 maj 2006 10:27 >> To: ubl-dev@lists.oasis-open.org >> Subject: Re: [ubl-dev] SBS and Restricted Data Types >> >> Hi Joe >> >> For example, in the ...-XPath.xml subset definition file you would >> have >> >> <Element name="Note" type="NoteType" prefix="cbc" >> uri="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponen >> t >> s- >> 1.0" >> >> minOccurs="0" maxOccurs="1" text=""> >> >> <Attribute name="languageID" use="optional" >> type="xsd:language"/> >> </Element> >> >> which could be restricted to >> >> <Element name="Note" type="NoteType" prefix="cbc" >> uri="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponen >> t >> s- >> 1.0" >> >> minOccurs="1" maxOccurs="1" text=""> >> >> <Attribute name="languageID" use="optional" >> type="xsd:language"/> >> </Element> >> >> making the Note mandatory. This way the SBS mechanism allows >> restrictions to cardinalities. A reminder that the resulting >> instances > >> have to be valid according to non-subset schemas too (in the SBS >> methodology) so only restrictions and not extensions are likely to > work. >> >> For facets we decided not to create a mechanism for the committee >> spec > >> definitions which would restrict string content - this is to avoid >> interoperability problems. If you are in a position to make use of >> facet restriction of strings, say with patterns, beyond just >> restricting cardinality, I'd suggest adapting the subset definition >> to > >> this in a way which agrees with your business partners but this is at >> your own discretion and outside of scope for the SBS methodology (at >> present). If you wanted, you could perhaps join the TC to get your >> method made public to help adoption and interoperability. In the >> meantime how about an attribute added here >> >> minOccurs="1" maxOccurs="1" text="" restriction-pattern="..."> >> >> I say 'restriction-pattern' because it has to obey XSD rules to still >> be valid for XSD - the resulting string, say, has to be schema valid >> in the document instance. >> >> This would need an extension to the subset definition schemas (XSD >> and > >> RNG). >> >> How does this answer things? I'd consider whether allowing >> restrictions as much as this doesn't create problems but it does make >> sense for implementers' >> own subsets so maybe UBL's SBSC should consider it as a specified >> extansion. >> >> As for how to create susbets in practical terms, along the SBS lines, >> there are a few things to consider >> + how to model the subset (the Small Business SC simply pruned UBL >> + schemas) how to generate subset definitions (SBSC used scripting) >> + the need to create one's own uuid for each definition how to >> + publish > >> + (SBSC >> >> + was created to create the definitions as UBL committee >> specifications and premanently publish them as such in >> http://docs.oasis-open.org/ubl/ for widest use and >> interoperablility) >> + how to associate the subset definitions (and maybe codelist files, >> + etc) >> with the business process definitions and trading partner agreements >> (the SBS methodology only provides a mechanism for doing this with >> ebXML) >> >> A further point is that restrictions of enumeration values are a >> special case. >> Say you wanted to restrict a code - there is the Codelist Methodology >> for that (in progress for UBL in general but version 0.3 is for UBL >> 1.0). >> If you wanted to restrict an Identifier to add enumerations (as well >> one might for an implementation, for example with a tax type ID) then >> I hope the same codelist methodology could be used, perhaps creating >> one's own genericode files for the identifiers and codelist >> association files to relate them to the individual instances >> (document > >> contexts) of the IDs in the documents. >> >> All this relies somewhat on one's being in a position to create one's >> own subset definitions, codelist genericode files and association >> files and to associate them with the actual transaction arrangements >> and publish them. >> The SBS especially provides all this somewhat to aid interoperability >> as widely as possible and also to aid adoption where the above said >> position is limited. >> >> All the best >> >> Stephen Green >> >> >> >> >> >> >> Quoting Chiusano Joseph <chiusano_joseph@bah.com>: >> >>> Please pardon me if this question has been asked before on this list >>> (my searches indicated the contrary): >>> >>> In terms of the SBS, what is the best way (if any) to restrict data >>> types of a UBL schema for an specific implementation? Whether it is >>> a > >>> 1.0 or 2.0 schema does not matter for purposes of this question (at >>> least I don't believe so). >>> >>> For example, what if one had a need to define an xsd:minOccurs or >>> xsd:maxOccurs facet for an xsd:string data type, for their own >>> implementation? >>> >>> Thanks, >>> Joe >>> >>> Joseph Chiusano >>> Associate >>> Booz Allen Hamilton >>> >>> 700 13th St. NW, Suite 1100 >>> Washington, DC 20005 >>> O: 202-508-6514 >>> C: 202-251-0731 >>> Visit us online@ http://www.boozallen.com >>> <blocked::http://www.boozallen.com/> >>> >>> >> >> >> >> >> --------------------------------------------------------------------- >> This publicly archived list supports open discussion on implementing >> the UBL OASIS Standard. To minimize spam in the archives, you must >> subscribe before posting. >> >> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >> Alternately, using email: list-[un]subscribe@lists.oasis-open.org >> List archives: http://lists.oasis-open.org/archives/ubl-dev/ >> Committee homepage: http://www.oasis-open.org/committees/ubl/ >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >> Join OASIS: http://www.oasis-open.org/join/ >> >> >> --------------------------------------------------------------------- >> This publicly archived list supports open discussion on implementing >> the UBL OASIS Standard. To minimize spam in the archives, you must >> subscribe before posting. >> >> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >> Alternately, using email: list-[un]subscribe@lists.oasis-open.org >> List archives: http://lists.oasis-open.org/archives/ubl-dev/ >> Committee homepage: http://www.oasis-open.org/committees/ubl/ >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >> Join OASIS: http://www.oasis-open.org/join/ >> >> > > > > > --------------------------------------------------------------------- > This publicly archived list supports open discussion on implementing > the UBL OASIS Standard. To minimize spam in the archives, you must > subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Alternately, using email: list-[un]subscribe@lists.oasis-open.org > List archives: http://lists.oasis-open.org/archives/ubl-dev/ > Committee homepage: http://www.oasis-open.org/committees/ubl/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > Join OASIS: http://www.oasis-open.org/join/ > --------------------------------------------------------------------- This publicly archived list supports open discussion on implementing the UBL OASIS Standard. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Alternately, using email: list-[un]subscribe@lists.oasis-open.org List archives: http://lists.oasis-open.org/archives/ubl-dev/ Committee homepage: http://www.oasis-open.org/committees/ubl/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php Join OASIS: http://www.oasis-open.org/join/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]