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: Re: [ubl] Re: [ubl-dev] Treasury Tag Pattern: to 'glue' two instances having different schemas


Duane

> >
> DN - I find it troublesome that someone creates a single element that
> may have multiple names and no constraints on content (aka "any") and
> they call it a "standard".  What is that?  XML already states we can do
> this.  What is the standard?  Is it an enumerated list of names the
> element might have?  You cannot even express this properly using W3C
> Schema since it is far too ambiguous for anyone to ever process unless
> you make a huge "if.. else" construct:
>
> // in java...
> for (Int i = 0; i < SBDHNames.getLength(); i ++)
> {
> String SBDHName = myList.SBDHName[i];
> Element foo = (Element) Document.getRootElement();
>             if (foo.getElementName().equals( SBDHName)) {
>                     // do something with it
>                }
> }
> // repeat as necessary....

I'm not sure though what the problem difference is between a datatype
allowing any string (xsd:string) and one allowing any XML (xsd:any).
The latter is, after all, a structured form of the former with * more *
opportunity for control of form and of resuse. The string can be constrained
by a pattern, etc and the XML by a schema. What really is the difference?
I'd say the XML was preferable to the string. After all, what is better
in a business message:

<Order xmlns="urn:oasis:names:specification:ubl:schema:xsd:Order-1.0"
><ID>123</ID>...</Order>

  = xsd:any content

or
<![CDATA[ <Order
xmlns="urn:oasis:names:specification:ubl:schema:xsd:Order-1.0"
><ID>123</ID>...</Order> ]]>

  = xsd:string content

The latter is harder, more expensive to process and could hide all sorts of
things
and is ignored by validating parsers, ... the objections could go on.


> >
> >
> DN - you can do that but the danger is that the receiver has to
> potentially handle all combinations.  You would have to have some out of
> bandwidth agreement with the receiver to recognize what ones they will
> process and which messages they will not.  This is usually the case
> anyways.  The receiver just writes a simple test to see if the one they
> handle is there and if it is not, they generate a message and send it
> back basically stating that "the message you sent is not supported".
> This is where WSDL is very useful since you can bind a service to a
> specific schema.  CPP can also do this although it is not as widely
> supported.
>
> >I'd prefer that we had a schema with
> >a multi-occurance xsd:any element/type but
> >in its absence I'd settle for a pattern as
> >above and hope that it provides at least
> >some interoperability - essentially it means,
> >I think, the establishing of a convention.
> >
> >
> DN - agree with UBL thinking.  xs:any is harmful for interoperability
> since an instance may pass but could have anything in it.  It also
> leaves the door wide open for DoS attacks (a couple hundred mbs of CDATA
> could be added to messages and they would be processed).  I favour use
> of xs:import or make a UBL top level element that MAY contain 0..1
> instances of any number of other UBL schema fragments.  XoP is probably
> not the best solution here and you should not even consider using
> something as vague as the SBDH work IMO.

I'd regard xsd:string as more likely to lead to the inclusion
of hundreds of Mb of CDATA (see above).

Are we really sure we are doing the right thing here?

Finally, xsd:any allows control of namespaces through ##any etc
so it isn't as 'bad' as many make out. It really is just an XML datatype
and even mainstream databases, Java SDK, etc are starting to incorporate
the XML datatype at last. I admit it does need risk assessment though
so I'd rather not push this too far without accepting that a lot of
discussion
and plenty of foresight is necessary here.

All the best

Steve


>
> Duane
>
> >
> >
>
> ---------------------------------------------------------------------
> 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]