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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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


Subject: SV: [ubl] Extension Element Action item SV: [ubl] Minutes of Atla ntic UBL TC call 5 April 2006


Hi Mike

If we do not allow new attributes then we may need to define a ABIE that
contains the (XSD:Any).

Michael: In the PSC we would like to add an attribute called Context and an
attribute called Subset to alle DocumentTypes. Does the rule about not to
define new attributes also imply the we can't do this?

Kind Regards

Peter

-----Oprindelig meddelelse-----
Fra: Grimley Michael J NPRI [mailto:GrimleyMJ@Npt.NUWC.Navy.Mil]
Sendt: 26. april 2006 16:28
Til: ubl@lists.oasis-open.org
Emne: RE: [ubl] Extension Element Action item SV: [ubl] Minutes of Atla
ntic UBL TC call 5 April 2006


All,

How about two rules:

    [CTDx] The xsd:any element MAY only be used within the 'UBLExtension'
element definition, and with xsd:processContents set to 'skip'.

    [ELD9] The 'UBLExtension' element MUST only be declared immediately
following the 'UBLVersion' element within the document schema, with
xsd:maxOccurs="1".


<Bryan>"The attributes I propose are..."</Bryan>

We currently do not allow attributes not defined by CCTS. Also, even those
are only allowed on leaf nodes (BBIEs). I recommend capturing all  this info
in elements; let's try to minimize the 'damage'...

Also, maybe these should be captured within the 'custom' element that will be
a child of the 'UBLExtension' element. After all, this is information about
*that* element, and not the 'UBLExtension' element. What do you think?

Thanks,
Mike

-----Original Message-----
From: Bryan Rasmussen [mailto:BRS@itst.dk] 
Sent: Tuesday, 25 April 2006 0714
To: ubl@lists.oasis-open.org
Subject: [ubl] Extension Element Action item SV: [ubl] Minutes of Atlantic
UBL TC call 5 April 2006



Hi, 

The following is what I figured could be the NDR text for xsd:any:

5.2.7 xsd:any Element
 UBL allows the use of xsd:any under controlled circumstances, because this
feature permits the introduction of  potentially unknown elements into an XML
instance the processContents attribute of the element must always be set to
skip as this will remove possible errors in the validation layer. The xsd:any
construct is  seen as aiding the requirements of interoperability and as
mainly be useful in cases where organizations that wish to use UBL are
required by law to send additional information not covered by the UBL
document structure, thus extending the UBL message. Since it is a priority
that  there can be meaningful validation of the UBL  document instances
xsd:any must be used sparingly, and only within UBL defined elements meant
for containing non-UBL elements that can be understood to extend UBL. Any use
of xsd:any must also only allow no more than one element in the non-UBL
namespace, this is to ease serialization of the extending element as its own
XML instance that c
 an then
be validated, if an implementer wishes to do so, outside the UBL validation
process. 
 [ELD9] The xsd:any element can be used, with processContents set to 'skip'
and minOccurs=1, maxOccurs=1.

-----------------------------------------------------------------------------
-----------------------------------------

The following is a very rough suggestion for how the element should actually
look  but Peter and I think it's a reasonable starting point to open up for
discussion, it's taken from my original suggestions for how an Extension
element should look, I suppose the name will be ExtensionPoint instead of
ExtensibleContent:


An ExtensibleContent area is an element in the understood format document
that contains another format not related to the overall document format. 


The contents of the ExtensibleContent area can be further specified by those
doing the extending via attributes on the element itself. 

The attributes I propose are 

ExtensionID - same semantics as schemeID

extensionAgencyID - same semantics as schemeAgencyID for Extensions

extensionAgencySchemeID - same semantics as schemeAgencySchemeID

extensionAgencySchemeAgencyID - same semantics as schemeAgencySchemeAgencyID


extensionReason - a codelist, I can think of 
a.	Legal - the extension contains information required by in an area
covering the extending body for documents of the type being sent.
b.	ReceiverRequested - the extension contains information that the
receiver has requested be provided. 
c.	ProvisionalTest - the extension is currently passing information that
is being considered for inclusion into the next version of UBL, this would
presume some sort of public repository of currently considered extensions.
The sender is testing how the extension works in their system with trading
partners. I'm not very wedded to this particular reason, as I'm not sure if
it is something I would describe as a 'reason'.
d.	Application - the extension is a vendor specific extension

mustUnderstand - a Boolean, only allowed in contexts of the extensionReason
being legal, the sending party is claiming that in order for their document
to be received validly the receiving party must understand it. I realize of
course that this raises the spectre of balkanization again, but it seems to
me that this would only be used when actually required by law, given that who
in their right mind would send a document and require someone to understand
it if it meant that by not understanding the receiving party could refuse it.


extensionAgencyControllerID - in the context of the Danish UBL project the
Danish Government ministry in charge of the technical wing of the project
would be the Controller for any official extensions. 


extensionAgencyURI - a dereferenceable uri where information about the
extension can be found. 

extensionDomain - the problem domain that the extender considers the
extension to cover. 
	          Some evident domains - 
a.	Presentation, handled via SVG, XHTML?
b.	Calculation, handled via MathML?

Of course these are more evidently application extensions than semantics
extensions. 

ExtensionDomainSchemeURI: a dereferenceable uri that will define the domain. 

-----------------------------------------------------------------------------
---------------------------------------------

Do these seem like reasonable attributes of such an area?

Cheers,
Bryan Rasmussen

-----Oprindelig meddelelse-----
Fra: Bryan Rasmussen
Sendt: 20. april 2006 12:46
Til: 'Grimley Michael J NPRI'
Cc: 'jon.bosak@sun.com'
Emne: SV: [ubl] Extension Element Action item SV: [ubl] Minutes of Atlantic
UBL TC call 5 April 2006



Hi Mike, 

Here is my stab at what the NDR should say for allowing xsd:any:

5.2.7 XSD:Any Element
 UBL allows the use of xsd:any under controlled circumstances, because this
feature permits the introduction of
 potentially unknown elements into an XML instance the processContents
attribute of the element must always be set to skip as this will remove
possible errors in the validation layer. The xsd:any construct is
 seen as aiding the requirements of interoperability and as mainly be useful
in cases where organizations that wish to use UBL are required by law to send
additional information not covered by the UBL document structure, thus
extending the UBL message. Since it is a priority that  there can be
meaningful validation of the UBL
 document instances xsd:any must be used sparingly, and only within UBL
defined elements meant for containing non-UBL elements that can be understood
to extend UBL. Any use of xsd:any must also only allow no more than one
element in the non-UBL namespace, this is to ease serialization of the
extending element as its own XML instance that can then be validated, if an
implementer wishes to do so, outside the UBL validation process. 
 [ELD9] The xsd:any element can be used, with processContents set to 'skip'
and minOccurs=1, maxOccurs=1.

I've cc'ed Jon but haven't posted to the list yet.

Seem reasonable for the NDR requirements?

Cheers,
Bryan Rasmussen




-----Oprindelig meddelelse-----
Fra: Bryan Rasmussen [mailto:BRS@itst.dk]
Sendt: 19. april 2006 12:46
Til: jon.bosak@sun.com; ubl@lists.oasis-open.org
Emne: [ubl] Extension Element Action item SV: [ubl] Minutes of Atlantic
UBL TC call 5 April 2006


>   AGREED that the document extension area should go at a high
>   level, but last in the schema.

>   ACTION: PB and BR to submit a more detailed proposal along
>   these lines, possibly contacting MG offline; for submission
>   week after next at the latest.  (Next week is the Easter
>   holiday in Europe.)

Due to various issues around vacations and work schedules Peter and I haven't
had an opportunity to talk together. 
It was my understanding that this Action Item was actually to be split into
two, that is to say how should xsd:any be allowed in the Naming and Design
Rules (which was the part that Mike Grimley volunteered to read over), and an
item on how the element should look. Is this correct? 

I had planned on doing the NDR item over my vacation, but as it was a
capoiera workshop where I ended up training 7+ hrs per day and dancing all
night as part of the workshop's social obligations I ended up only being able
to do about 3 hours of the work I'd intended to do over my vacation, and none
of that was on the NDR (yet strangely, I am quite happy ). However I figure I
can have the NDR part of the item later on this week, if that is in fact
still part of the action item.

Sorry for the inconvenience, 
Bryan Rasmussen  

  

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



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