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

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

> 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