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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-cmsc message

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


Subject: [ubl-cmsc] Minutes (raw) from 18-22 March 2002 NDR/CM SC meetings inBarcelona


Below are notes taken from various NDR SC, CM SC, and joint NDR/LC SC 
sessions at the third UBL F2F meeting in Barcelona 18-22 March 2002.

The NDR SC is not meeting this week, but will hold our regular telecon 
on April 3 of the following week.  European summer time starts on 
March 31, but note that the U.S. DOES NOT change until the April 7. 
Thus, some participants may have to adjust their schedules by one 
hour.  (I will try to include this information in the agenda for next 
week's meeting.)  Everyone, please note your action items and try to 
publish new versions of position papers in plenty of time for people 
to read them.

Following is the agenda actually adhered to by the "technical"
SCs during the week:

=========================
Monday afternoon
- NDR SC
   . Agenda planning
   . Code lists

Tuesday morning
- NDR SC & LC SC
   . Simple types/RTs/CCTs and facets
   . Code lists

Tuesday afternoon
- NDR SC
   . Native context
   . Role model discussion
   . Schema code review (partial)
   . Role model ratification

Wednesday morning
- CM SC
- CC SC
- NDR SC
   . Schema code review (continued)
   . Doc types wrt business process

Wednesday afternoon
- CM SC

Thursday morning
- CM SC
- NDR SC
   . Schema code review 11am-12:45pm

Thursday afternoon
- NDR SC
   . Schema code review as necessary
   . Doc types wrt business process
- CM work

Friday morning
- NDR SC
   . Collect and prioritize remaining work
   . Action items
   . Write the report to the plenary
- NDR SC & LC SC
   . Schema code review results
   . Generic terms where underlying meaning is the same
   . Containership benefits
   . List of document types in scope
   . Recommendation on number of document types
- UBL Plenary
=========================


Joint NDR/LC session, 19 March 2002

Simple Types, RTs, and CCTs:

The LC SC's interpretation of the CC technical specification
is two-fold: it provides a naming convention and an
architecture of components.

A core component type (CCT) is an abstract or logical view of
how a piece of information will physically look. For example,
it's a date (DateTime.Type), or a piece of text (Text.Type),
or a code (Code.Type).  There's a fixed set of 11 of these
types. They might seem like XSD primitive types, but CCTs
might have structure so they don't fit easily into XSD's
simple/complex distinction.

For example, "numeric" is just a number.  But "identifier" has
a value, an agency, a scheme name, and a language.  And "code"
has a value (e.g., "USD"), an agency (e.g., "ISO"), a version
(e.g., "9612"), and a name (e.g., "currency code" -- the name
of the list).

In the draft UBL schema, there is currently a schema module
containing a core library of XSD types that correspond to
CCTs.

On the other hand, representation terms (RTs) are *terms*, not
types.  Their purpose is to describe how an object is
represented.  For example, a currency can be represented by a
code or by a description.  A RT is a little bit like a file
extension that tells you what you'll find inside.

There is a many-to-one relationship between RTs and CCTs. All
of the higher-level XSD types in the draft UBL schema build on
the XSD types defined for CCTs.

However, we know of a few cases where this is problematic: If
you need an identifier to be supplied as either a code
(Code.Type) or a description (Text.Type), this would make the
relationship many-to-many.

What if we needed to add CCTs? The CC technical specifiction
(V1.8) defines lists of RTs and CCTs.  Even though we're
planning to give feedback to UN/CEFACT about our new needs in
this area, the LC SC has decided to use only official RTs and
CCTs even if our suggestions for new ones aren't accepted.

However, the LC SC has added a column to the spreadsheet
called "Type" that allows for additional structural "CCTs" at
the aggregate level.  They are equivalent to CCTs (or is it
RTs??), but they give more specifics than the "Details" RT
allows. For example, several elements are of the "Contact"
Type and the "Details" RT.

We believe that Identifier.Type is broken as a CCT. However,
Identifier as a RT merely conveys "identification" logically,
which would be okay except that in different circumstances you
want to map it to different CCTs (different structures):
Identifier.Type, Code.Type, and Text.Type.  There may be, we
believe, other cases of one-to- many mappings; Sue Probert and
Mike Adcock will know for sure. The problem will occur
whenever the same thing appears on both sides of a RT/CCT
table.

What the LC SC is actually doing in naming tags is to
concatenate their private "Type" field with the Rep Term
field, but drop one whenever they're identical.  What they're
doing in binding types to elements is to define XSD types
corresponding to their private "Type" field and use that.
(See the "Re-used Types" sheet of the LC SC spreadsheet.)

ACTION: The NDR SC to reexamine its naming rules to conform to
what the LC SC is actually doing, because we believe that our
rule on element naming is (a) insufficient and (b) not as good
as what the LC SC is doing.

The NDR SC has been considering whether to put XSD type names
in element names at all (the "role model" paper); if you do
put it in, you can only do many-to- one mappings of property
terms to types.  If you don't put it in, you can have a many-
to-many relationship (e.g., if "Contact" in "ShippingContact"
refers only to the property term and not the type, you can
have different elements containing contact information that is
represented in structurally dissimilar ways.

ACTION: Mavis to revise the tag structure paper with our
latest thoughts on RTs vs. CCTs and how schemas should define
types for them.

Ontologies (Peter Yim):

Leo Obrst is on the W3C Web Ontology WG; he works for MITRE
and has a course on the topic.  Jack Park is on the Topic Maps
TC and has authored the first book on Topic Maps.

SOUL is the Semantics Ontology Universal Language.

We are invited to attend the April 2 LC SC meeting by means of
NetMeeting in order to hear the ontologies presentation.

Code lists:

ACTION: Eve to revise the code list position paper to include
discussion of the new idea (moving code list identification to
a namespaced element containing a code from a single list) and
the other ideas proposed by EWG attendees.

NDR session, 19 March 2002

Attending:
Eve
Bill
Gunther
Fabrice
Mavis
Mark
Paul
Arofan
Eduardo
Phil (partial)

Native Context:

It was noted that A2A (Ron's use cases) and B2B are getting
increasingly similar, though they're not identical.

Our charter is to define our semantics in terms of the CC
model, and we are especially concerned with bringing
functionality to a SME audience. The UDEF model provides a
different (though related) set of semantics, in an
architectural forms-like manner.  Perhaps it would be more
appropriate for UDEF semantics to be submitted to the CC work
for incorporation.

Given that there can be many different sets of semantics to
which we might have a relationship, should we accept all
contributions of attributes that link back to those sets? only
some of them (based on what criteria)? none of them (such that
an extension needs to be created in order to add them)?

We're clear that we don't want to do the work of the mapping
ourselves, particularly since additional opportunities for
mapping might arise later.  We're unclear that there's demand
yet for UDEF.  It's easy enough to consider adding support
(whether by an internal mapping, such as UBL attributes, or by
an external mapping, a la RDF/stylesheet/context methodology)
when the demand is clear.

MOTION: Refer Ron's proposal to the LC SC with a
recommendation that it not be adopted as part of core UBL but
rather considered as a possible extension that external
parties could create. Motion passes unanimously (with Gunther
absent).

ACTION: Eve to send mail to Tim and the LC SC to relay this
decision.

Role Model paper discussion:

Option 0 is role-based naming of elements.  This is what Bill
proposes.  This would have the tag name be the Property Term.

Option 1 is that if tag names of two elements match, then
their type assignments much match.  This was proposed at the
last F2F.  In this general case, you have to have a database
of previously assigned names so that your new names don't
clash.

Option 1a is using the name of the assigned type directly in
the tag name.  This is what the LC SC is currently doing.  We
might consider this a "habitable" style of XML instances,
since it informs you helpfully about the types of things as
you read along.  You have useful information about the data
without having to consult the schema.

Option 2 is that if type assignments of two elements match,
then their tag names must match.  However, two elements of two
different types may share a tag name. This is not viable
because you'd have to make two elements of the same type
(buyer vs. seller address) get the same tag name, or
alternatively define lots of trivial type derivations.

Option 3 is one-to-one correspondence between types and tag
names.  This is tantamount to globally declared elements
(which, by definition, share a single namespace and whose
names can't overlap).

The LC SC has a notion of CCTs; reused complex types in the
core UBL Library; and complex types that are specific to a
functional area. Their current naming rules are different for
element naming depending on which type is assigned to the
element:

- For elements with a type from the CCT package, the rule is:

   PropertyQualifier + PropertyTerm + CCT (but fold final two
   fields if equal)

- For elements with a type either from the reused type package
(the UBL Library) or from a functional area package (e.g., the
Order module), the rule is:

   PropertyQualifier + PropertyTerm

Thus, the LC SC is currently using a combination of Option 0
(for aggregates) and Option 1a (for basics).

"Structural" information appears in the definitions of both
CCTs and RTs.  The definition of CCTs provides requirements on
supplementary components, and sometimes the structure of the
main content component.  The definition of RTs provides
structural requirements on the main content component.  This
is the main reason for the many-to-many problem exemplified by
"Identifier".

Here are the role model choices:

A Keep their current 0/1a strategy, with two formulas
distinguished by aggregate vs. basic and with application of
exceptions as recommended by NDR.

B Advise them to move to a 0 strategy, change the formula that
implements 1a to implement 0 throughout, and re-examine all
the rows so changed in case they want to augment the existing
Property Term to include type information for semantic
clarity.

C Advise them to move to a 1a strategy, change the formula
that implements 0 to implement 1a throughout, and re-examine
all the rows so changed in case they want to further
distinguish the Property Term field from the Type field so
that nothing gets elided, or even ensure that it's identical
so that one does get elided. (If we choose C, we have to
figure out the RT/CCT problems and re-examine our exceptions
to the RT naming rule.)

We didn't re-vote on the entire matter because option A was
previously decided, other than the motion below.

MOTION: In those cases where it seems beneficial to have two
elements that have the same tag name but are bound to
different types, as is currently the case with the BIE
Order.Header.Details (tag name Header), it is permissible.
Motion passes with Mark C. objecting.

ACTION: Bill to update the role model paper to record the
latest decisions.

CM session, 20 March 2002

Use cases collected at the previous F2F meeting:

We can't be very precise because we don't have the "final"
versions of library structures.

1 Cellphones in Switzerland must be sent to personal address

Context:
   Region = Switzerland
   Product code = Cellphone
   Add personal address or make
   personal address required

Assumptions: A corporation is buying a bunch of phones for its
employees.  The phones will be shipped individually to the
employees at their home addresses. This happens to an Order
document.

Actions: Beneath the line item level (because the phones might
not be the only thing in the order), remove the original
shipping address (Address in FinalRecipient in Item) and
insert a set of shipping addresses that are restricted to
being personal. Could do this by deriving a new type for that
FinalRecipient that extends the cardinality of Address, and
use xsi:type in the instance, except that it happens to be the
case that you can't extend cardinality of a "middle child"
with derivation.  Thus, you need transformation for this
("dotted-line derivation").

The original instance would look like this:

<ubl:Order>
   ...
   <LineItem>
   ...
     <FinalRecipient>
       ...
       <Address>

An application of a context rules document that uses
derivation as much as possible ("derivation-when- possible" or
DWP) would look like this (except that xsi: type is just shown
to indicate where UBL named types can be reused and where they
can't). Because only named types, and not our local
unqualified elements, are available to extension designers:

<my:Order xsi:type="my:order">
   ...
   <my:LineItem xsi:type="my:lineitem">
     <my:this xsi:type="ubl:whatever">
     ...
     <my:FinalReceipient xsi:type="my:finalrecip">
       <my:that xsi:type="ubl:whatever">
       <my:Address xsi:type="ubl:AddressType">
       <my:theother xsi:type="ubl:whatever">
       ...

Consequences of the DWP approach:

- You always have to create a new message type.

- Because only named types are reusable, you have to create
your own new elements for everything that's "touched" all the
way up. Directly in the ancestor chain, you can't ever reuse
UBL types.

An application of a context rules document that does
transformation at all times (TAAT) would look like this. A
putative global attribute ubl: type is shown to indicate what
UBL named types are being "implemented" as an "interface" in
this foreign global element; that is, this element promises to
have subelements with semantics and positions and
cardinalities that are identical to UBL's OrderType).  The
elements inside the foreign global Order are declared to be
local and unqualified, just like UBL, except that they're
defined relative to the extension schema that was generated:

<my:Order ubl:type="ubl:OrderType">
   ...
   <LineItem ubl:type="ubl:LineItemType">
     ...
     <FinalReceipient> <!-- doesn't match UBL -->
       ...
       <Address ubl:type="ubl:AddressType"> <!-- 1..n -->
       ...

Consequences of the TO approach:

- You always have to create a new message type, just as with
the derivation-when-possible approach.

- You have to redeclare everything "touched", just as with the
derivation-when-possible approach, but you don't have to try
to reuse UBL named types.  In fact, since the entire schema is
being transformed, you are actually redeclaring every single
thing, not just those things "touched".

- All ancestor elements above the site of change, except for
the direct parent element, can "implement the UBL interface"
exactly.  If the transformation uses local elements for these
ancestors (something we probably want to dictate), they look
just like UBL.

Observations:

- With the TAAT approach, local elements are quite nice
because all existing XSLT (except for any templates that
operate on the site of change) still works.  This made us
think that having even the top-level element be local would be
desirable.  This means that we'd only use the concept of
namespaces

- With the DWP approach, local elements are the ones that seem
inconvenient because you can't reuse any of the elements in
your extension directly; you have to map your own elements to
the types that UBL has made available for reuse.

- The TAAT approach allows you to encapsulate the change
better, assuming that you don't mind having redeclared every
last little thing (by means of a trivial transformation).
Clearly it would be necessary to add annotations to the
transformed schema that indicate what was done.

Below are Eduardo's notes on the use case discussion. ">>"
precedes his comments on each original use case.

1* Cellphones in Switzerland must be sent to personal address
         Region = Switzerland
         Product code = Cellphone
         Add personal address or make personal address required

 >> ship to address must be burst out into personal addresses

rule needed: derive a type from another and change the
cardinality of a child (number of addresses) -> transformation

2* Requirement to have currency in price would depend on
whether it is a local or crossborder transaction -- WE NEED A
BETTER EXAMPLE

 >> This example does not seem to be relevant

3* Europe has VAT associated with price, in US it is already
included

 >> Not clear what the problem is, not clear what the
requirement is.

4* Note of fiscal type is required in invoice header in Brazil

 >>   no need to declare a new global type - add a new element
of string type to the header (XSD derivation doable in this
case)

5* Payment reference number required in invoice header in
Scandinavia

 >>   no need to declare a new global type - add a new element
of string type to the header (XSD derivation doable in this
case)

6* Transport of hazard goods required additional fields:
chemical constitution in addition to product name, contact
information (many others) in line item at different points in
the document

 >> it's actually more than in line items, it may be throughout
the schema. XSD extension to various types would be possible,
as well as extension at the end of the header. But it's not
clear whether this would be enough, as there may be choices
involved, and XSD does not add OR leaves.

7* Same for storage (but different set of fields), so relevant
for inventory

 >> ditto

8* Some might apply only if its shipped at sea

 >> this is very similar to case 1, so can't use XSD extension

9* When shipping goods to countries that America doesn't like
(some acronym), certificate of origin is required (several
cases, like to Arabia from Israel, vice versa, etc.)

 >> change of cardinality but XSD derivation is possible

10* Host of examples around certifications (e.g. Bordeaux wine
is actually Bordeaux), requirements vary by country

 >> straight extension by derivation (as far as we can figure
out)

11* UK and ex-dominion countries, account name has superiority
over number, in other countries the reverse is true (deciding
which field is optional)

 >> change in cardinality - change at least one required to
optional

12* Certain items in PO line items (credit card name and
address for UK and a number of EU countries) is private, has
to be masked out when sent to a third party -- NEED FOR
SOMETHING THAT'S THERE BUT MASKED

 >> not our domain - it's security

13* In Singapore, the government generates all PO numbers
(maybe for imported goods only)

 >> Cardinality issue again, but XSD derivation is ok

14* For tax-reporting purposes you must report tax rate in EU

 >> this is ambigous - it may be a cardinality issue (must, but
ok for XSD extension) or an extension issue (tax rate and
supporting information)

15* In the Czech Republic, tax summary must be included with
0, 5 and 22 tax rates and amounts

 >> restriction of tax rates; change of cardinality in tax
summary to required, may need addition of fields to tax
summary, restriction of allowable values in tax rates or
addition of three required sets of different rates, and may
need removal of required field. Cannot be done with XSD type
derivation.

16* In Australia, customs make a distinction at a line item
level: when the item is composed of products from other
countries, each item must be included in a separate line item
(e.g. 25 bales of cotton, some from India, some from
Bangladesh, you would need 2 line items)

 >> Needs change of cardinality in country-of-origin in
lineitem to required - fine.

17* When publishing catalog content, depending on whether you
are the originator or the republisher, if you are a
republisher, you need to include the manufacturer's part
number as well as your own part number

 >> change of cardinality from opt to required. OK

18* Consolidating shipper consolidating on behalf of several
forwarders, who are also shipping on behalf of several
consonors, the info that is provided to the guy up the
hierarchy has to be filtered from the info provided down the
hierarchy. E.g.: cost of transport is provided to the supplier
but not to the customer

 >> this use case  does not affect the schema, just the
instances.

19* When an order request becomes an order, you must put in a
buyer request number (optional becomes required)

 >> typically it's either extension - or as a different doctype

20* US government requires a government bill of lading in
addition to the normal bill of lading

 >> is it two different doctypes? Does not seem to apply here.
Not enough information

21* The contents of the bill of lading or way bill depends on
mode of transport

 >> Same as mode of transport above? Not clear

22* Tax exemption depends on project because some work is done
for a public body and some work is done for a private company,
so the tax information might not be required

 >> if it's change from required to optional, as it seems to be
the case, XSD derivation cannot apply.

23* For lodging, there is a check-in date and check-out date,
reservation number. For car rental there is check- out date,
check-in date, number of miles driven, vehicle class,
insurance, security deposit, vehicle registration number

 >> field additions, plus name change (TAAT)

24* For airlines, there is a carrier code, fare basis, flight
number, originating city, destination city, number of stops,
stopovers, service class, reservation number

 >> field additions, etc, same as 23

25* In automotive, the VIN number is part of product
description. Some companies in manufacturing add GPS info to
delivery information.

 >> adds an elemt (VIN), or we're gutting name/address, but
derivation cannot be used.

26* In Australia every invoice has to contain an Australian
business number of invoicing party.

 >> XSD derivation would not work for cardinality change, but
one could be added at the end.

27* Some rule is applied only to Europe interactions but not
to interactions inside Europe that are specific to certain
countries

 >> this is not a use case

ACTION: Eduardo to revise Arofan's original extension paper to
include all the latest CM information, and to communicate the
results of this F2F meeting to Matt.

NDR session, 21 March 2002

Schema code review:

We started by working our way through the spreadsheets.

- General comment: The spreadsheets are missing System
Constraints Context and Supporting Role Context.

- General comment: We note that there is no capturing of
precision (for numeric formats) and other similar constraints,
such as string lengths.  This will need to be captured at a
later date.

- General comment: We think we'll need a rule eventually about
how relationships (extra- hierarchical) get encoded in XML.
E.g., ID/IDREF, URI, application-specific IDs, linkbases, etc.
We wonder if the LCSC is sufficiently considering its
requirements about such relationships.

- General comment: Do not use specific words that have
different meanings in different industries (like check-
in/check-out, which are the opposite in hotel and rental
cars); instead, go for general terms (e.g. period-start,
period-end, etc.)

- UBL000002 (occurs other places as well): UBL Name should be
"BuyerID" because you're supposed to fold the property term
into the representation term when they're similar, and you're
supposed to truncate Identifier to ID.

- UBL000017: Is there a need to provide rules for constructing
models that allow for either a small- grained structure
(address postbox ID etc.) and a large- grained structure
(address line 1 etc.)?

- UBL000017: The structure seems unusually flat by XML, OO,
and database standards. While we're not against the use of
sequences, we suspect that developers may find it more useful
to have collections of elements that are "rolled up" into
container elements at an intermediate level (for example, rows
30-31 for country sub- entities).  The classic chunking
standard for human memory is 7 +/- 2, and standard operating
procedure for software developers and database designers is to
use this standard.

- UBL000017: We note that there's a lot of optionality of
elements. For example, there's nothing required in Address.
Are there interoperability consequences to this?  If the
context methodology is sufficient, is it better to allow
optional elements to be made required or better to allow
removal of elements?  Would intermediate containers help this
situation at all (e.g., you can make the container optional
and the contents required)? How is the "sweet spot" determined
on this?  As another example, we know that there will be other
kinds of things that we want to consider line items, but each
kind will have a different combination/cardinality of
contents.  We want to have a rule that the structures have the
maximum number of required contents, and where splitting the
structure into multiples will help, it should generally be
done.

Example: Line items contain at least quantity (1), part number
(2), and description (3). In certain stages of the process,
they also contain price information (4), tax information (5),
and shipping information (6).  So you have really four kinds
of line item: order, invoice, shipping, and catalog.  These
should be considered different rows.

- UBL000345: The choice of property term seems to obfuscate
the desired semantic here.  This is supposed to identify the
order from the buyer's perspective; something like "Buyer's
Order ID" would convey this better, though possessives in
English are suspect for tag naming.

- UBL000338 (as an example): The LineItem content in the Order
model, and likely many (most? all?) other things that have
0..n or 1..n cardinality, could usefully be grouped in a
containing structure (the xCBL ListOf... design pattern).  For
some (all?) 0..n things, it might be desirable to make the
container 0..1 and the contents 1..n.

ACTION: Eve to send the LC SC the schema code review results
in the form they require.

Document types wrt business process:

Should we ratify our potential design principle (appearing in
the Planning document and modnamver) that suggests creating a
new document type for each utterance in a business process?
Or should we combine some similar documents making up a
particular segment of a business process chain, and allow for
different emphases/requirements on their fields by making them
optional in all cases?  We think that new document types is
best.

MOTION: Ratify the one-doctype- per-transmission principle as
stated in the UBL Planning report and the modnamver paper.
(Attending on 22 Mar '02): Eve, Fabrice, Mavis, Bill, Gunther,
Phil, Paul, Arofan, Eduardo.)  Motion passes unanimously.

ACTION: Eve to communicate this to the LC SC.

CM discussion:

TAAT (transformation at all times) vs. Paella (Bill's proposal
for empty abstract interface types accompanying concrete
content-modeling types)

Paella pros:

- It doesn't break existing XPaths because references to local
elements remain functional except at the site of change.

- It's good for data binding because it's easy to render this
interface model into a Java- based (for example) interface
model; the approaches are very similar.

- It preserves the direct use of the UBL schema modules,
rather than writing out a modified version of UBL.  You don't
need to load the modified version if you already loaded the
original static UBL. Also, it lets somebody build a
specialization of UBL by hand without having to have a context
methdology engine available, or any other special tools.

- The ancestors of the site of change don't need to change,
the way derivation would require.

- We have all the expressive power to do any changes possible,
because the extra level of indirection allows us to define any
content models we want.  We don't have to use a hybrid
approach; we could all paella.

Paella cons:

- Because we don't have an obvious/simple relation between
types and elements, it's harder to get guidance from schemas
about what's going on by inspection.  This complicates the
generation of documentation.  (This is somewhat minor.)

- At run time, you have to load double the number of type
declarations in the core library.  (Though since half the
types don't do any real work, it's not that bad.)

- At run time, like TAAT, it relies on conventional
restrictions to the way it's applied to gain the benefits of
type declaration as expressed in Matt's paper.  That is,
"maximum understandability" of the empty interface type in the
face of derivations isn't much; if we want there to be
increased predictability in software behavior, we should stick
to the context rules that derive off of "real" types.

- The size of instances is increased because of all the xsi:
type attributes, even in vanilla UBL instances.  The size
factor isn't as bad as the "habitability"factor.

- Derived-from concrete types are always still available, even
if you don't want them to be.  This is sometimes a bug, but
sometimes a feature; that is, there are occasions in which you
will want to have both be available.

Assumptions about TAAT that we need to test:

- XPath behaves the same with TAAT as it does with Paella.

- Conventional restrictions are the same for TAAT as for
Paella.

- There is a perceived difference in complexity between the
two, but have no consensus on which is more complex for whom!

- Paella has bigger schemas for the core library, but smaller
additions.  TAAT is the reverse.

- It's more difficult to write a Paella-based context engine
than a TAAT engine.

- The two approaches are equally amenable to the "pipeline"
approach.

- Paella introduces issues of module management, which TAAT
does not.

- Paella sounds easier to digest!

The TAAT vision:

A type in the UBL schema has three elements.  We want to take
this type and delete one of the elements and add a new one.
We produce a new schema that has a type of the same name that
has the new content model (A, B,D instead of A,B,C).  The new
type is in a foreign namespace, rather than the UBL namespace.

It's possible to apply TAAT while importing/including whole
modules that don't need to change.

We are so far unable to prove that TAAT doesn't require
changing all the ancestors of the site of change.

Recommendation to the CM SC: Using Pipeline (
http://www.w3.org/TR/xml-pipeline) to describe input, output
and context rules in order ensures interoperability, and
obviates the need for Semantic Interoperability Document.

Auxiliary outputs:

While the XSD generated off the spreadsheet will be the
normative-form UBL schema, we discussed several auxiliary
outputs that we know already exist or have been offered,
including at least:

- ASN.1 schema (Paul)
- RELAX NG (no one signed up yet)

The following new issues arose:

- When should types be final and substitution groups be
   blocked?  This is likely to be related to the CM.

- Should the LC SC be considering extending the list of RTs?
   Yes.

- Containership (E.g.: Lack of nesting ends implies that XSD
   addition is performed at the end of large containers,
   potentially at the very end of the scheme.  The encouragment
   to add elements at the end of containers adds pressure to
   the tendency to add convenience containers, which multiply
   levels of nesting.)

- Dates and times

- Recurring types  (E.g.: elements that are functionally
   (but not structurally) substituable for each other may want
   to have an ancestor type in common that imposes no
   structural constraints (e.g. address vs GPS).)

- Modnamver

- Tag structure

ACTION: Arofan to start a position paper about containership.

ACTION: Gunther to provide a position paper recommending how
to handle dates and times.

ACTION: Eve to add "prioritizing" and "NDR document production
schedule" to the agenda for the next telecon.

ACTION: Eve to cancel next week's telecon reservation and send
mail about our not meeting next week.

ACTION: Eve to send final NDR/CM SC report to the appropriate
mailing lists.

-- 
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com



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


Powered by eList eXpress LLC