[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Units of Measure
Hi Martin, I agree that the XML Schema validation code hasn't the capability to validate the dynamic code (unless as you suggest it imports the dynamic table). I would establish (in or effectively in the Schema) an XLINK on the XML element that invoked the procedure that maintained the 'local' code list, checked the code value, etc. I'm just a 'reader' of the XML Schema and XLINK specs, and do not have detailed understanding of their implementations. So I don't know whether XML Schema would invoke the XLINK, or that would happen pre/post-XML Schema. But I feel confident that the link would get invoked before my application did. As you point out, XSLT could also provide the lookup service (and I suppose could be at the end of the XLINK rainbow). Don't know how that would play out either. I believe XLINK provides much more flexibility in handling dynamic codes, would be more efficient than 'sucking in' the entire dynamic code list (which might be excessively large), and so would be easier on the pocketbook. Consider a 'DUNS' number dynamic code list. The DUNS site might be able to provide the URL of the owner of the DUNS number (by looking it up based on the ownership component of the DUNS number). The specific DUNS number could then be looked up at the owner's site (and its semantic properties downloaded as well). As you point out, <appinfo> can have any application 'your application likes'. Well in that sense, 'our application' is ebXML. We get to decide what is is we like. If ebXML needs for example an XMI pointer, ebXML has to pin down its name/syntax, so that ebXML conformant systems can find and use it when appropriate. We need to move beyond "XML can do ..." to "ebXML does .. in this way". Cheers, Bob -----Original Message----- From: Martin Bryan [mailto:mtbryan@sgml.u-net.com] Sent: Wednesday, July 12, 2000 10:25 AM To: Miller, Robert (GXS); ebxml-core@lists.ebxml.org Subject: Re: Units of Measure >We seem to have a small > discrepancy however in what the Schema will contain. > > I observe that "automate creation of XML Schemas" implies a generation > 'source', such as RDF/XML (my current favorite) derived from a combination > of UML and BSR-like analysis of the metadata aspects of the desired > information exchange. The XML Schema <annotation> element also allows application specific data to be assigned to the element. This can have any content your application likes. For example, it could be set-up to look something like: <appinfo> <BSR-pointer URL=http://whereever.BSR.is/relevant-locator/> <XMI-pointer URL="http://www.ebxml.org/repositoryX/UMLmodel1234"> <rdf:Description .....> .... </appinfo> > I both expect and need to find a reference to the > 'source' in the Schema, as the 'source' will/should contain more > meta-information than will appear in the Schema. I say 'will/should' > because the extra information does not pertain to the validation of an > information exchange instance. Agreed, though there is nothing to stop there being more information in the documentation area as well (this can also contain embedded elements) >But this information does pertain to the > establishment of data transformation/application integration. So > this is the 'link' I refer to in my earlier messages. I would not expect it > to be traversed each time I processed an information exchange. > > Your distinction between static and dynamic code sets is also important. > But I don't support your suggestion that xsd:import be used to suck the > dynamic list into the schema. Rather, for each such coded element, I > support: > Provide access (in the schema) to a dynamic code validation process. How would you propose to do this given the current state of the XML Schema process. I can see no obvious way to do it. >The > process could/should keep a local table of known values. This sounds like a locally defined code set to my addled brain. > If invoked, when > it encounters an unknown value, it does a code lookup on the code source > site. The decision when to invoke the routine is left to the recipient. I can do this in XSLT using the xsd:otherwise option, but I can't see how we can invoke it in a Schema. Martin
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC