OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[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".


-----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:

      <BSR-pointer URL=http://whereever.BSR.is/relevant-locator/>
      <XMI-pointer URL="http://www.ebxml.org/repositoryX/UMLmodel1234">
      <rdf:Description .....> 

> 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
> 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.

> 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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC