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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

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

Subject: [ubl-ndrsc] RE: [ubl-cmsc] Minutes (raw) from 18-22 March 2002 NDR/CMSC meet ings in Barcelona

Great stuff! I'm impressed by how much you guys accomplished. I'm
particularly interested in the DWP vs. TAAT debate. Obviously I'm firmly in
the DWP camp, although I can see the problems with this (especially in light
of the limitations of XSD type derivation). Bill's Paella proposal looks
very clever (I haven't had a chance to review this thoroughly yet), besides
sounding delicious (I'm regretting Barcelona more and more...).

Anyway, I'm finalizing the brand new Context Methodology portal right now,
and I'd like to get the use cases on there with Eduardo's comments. There
are a number of things in the minutes that aren't entirely clear to me,
however. Would it be possible to schedule a call with someone (Eduardo?) to
discuss some of this and get me up to speed? If there is enough interest in
a follow-on discussion to organize a fully fledged conference call, this
would be another alternative. What is the general feeling on this?


> -----Original Message-----
> From: Eve L. Maler [mailto:eve.maler@sun.com]
> Sent: Monday, March 25, 2002 7:59 PM
> To: ubl-ndrsc@lists.oasis-open.org; ubl-cmsc@lists.oasis-open.org
> Subject: [ubl-cmsc] Minutes (raw) from 18-22 March 2002 
> NDR/CM SC meetings in Barcelona
> 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
>  >> 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
>  >> 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
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

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

Powered by eList eXpress LLC