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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

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

Subject: Re: [ubl-ndrsc] xsd:documentation vs xsd:appinfo

I'm sorry, but I'm at polar disagreement with the line of
reasoning that led to that conclusion, but without disagreeing
with the concerns about security.  Let me explain.

(Eduardo, I appreciate your clarification and am grateful
for leading on the discussion.  Please don't take any of
my words below as directing at personal level because I
don't know who suggested what.  And even if I do, I'm only
disagreeing with the points made.)

There're 4 aspects to my objection:
    (A) use of <appinfo>
    (B) concerns of applications executing <appinfo>
    (C) therefore dodging use of <appinfo> and filling 
        up <documentation> instead,
    (D) introduction of "normativity"

(A) Use of <appinfo>
We have a stated rule to follow W3C guideline, and it
is to use <appinfo>.  Any concerns with use of <appinfo>
should be done with XML Schema Working Group, not with
UBL TC.  Members who strongly feel that <appinfo> causes
security concerns should join XML Schema Working Group,
get it thrashed out and with opposing points debated,
then get a new version of XML Schema addressing those
issues at schema level.  

Once that is done (if it happens at all), applications 
claiming conformance to that new XML Schema spec would
automatically be safe, and businesses would feel better
about using those applications.

(B) Concerns of applications executing <appinfo>
This is a very strange thing to say.  XML Schema never 
specifies that applications MUST execute <appinfo>.
If some applications out-smart themselves by executing
information in <appinfo>, they're either providing extra 
"features", or creating problems to security people.  
But such happenings do not point to <appinfo> being a poor
mechanism for carrying application information.  It is
one thing to address them somehow, but it is another thing
to dodge its use because some "rogue" application chooses
to do that.

Going by this logic, we probably should stop using
any attachments in emails because SOME (not all) 
email clients provided extra features to automatically
or easily run presentations, executables, screensavers, etc.
Yes, the concerns with the security is certainly valid.
But no, the way to solve it is not to avoid using 

(C) Storing into <documentation> instead
The reasoning is very weak, because one cannot guarantee that
NO application will ever try to become "smarter" by detecting,
sensing, and then running any embedded codes within 
<documentation>.  The wolves go whereever the chicken go.

If UBL spec starts to promote storing data into <documentation>,
what stops the next version of "rogue" applications from
duplicating whatever codes they have for <appinfo> and
just replacing "appinfo" with "documentation"?

The proposed means to solve it simply does not solve it.
Not only that, the UBL metadata meant for machines now
sits in the realestate meant for human.  We lost two stones
with no bird, instead of killing two birds with one stone.

Going by this logic, we probably should stop using
any applications that executes comment blocks, right?
But just look at all the nice browsers around that
execute javascripts stored inside comment blocks of
webpages.  The assumed "safety" in <documentation>
just simply falls apart.

(D) Introduction of "normativity"
There's currently no such information about whether or not
a piece of metadata is normative or otherwise.  Looking at
the current draft-8 schemas now, one cannot tell if a piece
of metadata is or is not normative.  Wouldn't one expect
all such metadata from UBL spec to be normative?

If not, then the introduction of this idea about normativity 
of a metadata will be a metadata of that metadata.  In other 
words, for example, <ccts:RepresentationTerm> will need to
be marked with a boolean as to whether or not it is normative.
Likewise, <ccts:QualifierRepresentationTerm>, <ccts:ObjectClass>,
etc etc will all need an associated attribute to mark whether
they are normative.  The fact that a <ccts:xxx> metadata
is or is not a normative data should be explicitly marked
and not position-marked by depositing them in <documentation>
to mean normative and depositing them in <appinfo> to mean

If it sounds confusing, I think so too, as I think the need 
for the notion of normativity of each data is not so very
clear to me at all.

My conclusion is that that conclusion made by NDR not
so very long ago is not an appropriate way to address those
valid concerns.  Users and businesses do not choose to
adopt UBL just because UBL has "safely" stored data in
<documentation>, but because UBL does the right thing.

And I believe UBL's leadership in bringing to the world
a universal business language shouldn't be marketed on
the basis of avoiding the malpractices of some applications,
but to show leadership in doing what is standards conformant
and technically elegant.

Best Regards,
Chin Chee-Kai
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net

On Tue, 26 Aug 2003, Eduardo Gutentag wrote:

>>(I know this email will bounce from the FPSC and LCSC lists -- can
>>someone please forward it to them?)
>>It is true that you may have heard that the reason for keeping things
>>in "documentation" rather than in "appinfo" was that it's safer.
>>However, that's "safer" not from a security point of view, but
>>rather from an interoperability point of view. The reasoning is
>>that appinfo may not be implemented equally among all applications,
>>and in particular that some sites/organizations/businesses are
>>known to forbid applications that interpret "appinfo" precisely
>>as it's intended, that is as machine-readable (and executable) data,
>>indeed for security reasons. The agreement we reached in NDR not too
>>long ago was that while it is ok to put in appinfo non-normative
>>data, normative data should never be put in it because we'd run the
>>risk that it may never be processed.
>>I am sure that Mark and others may have more to say about this.
>>Chin Chee-Kai wrote:
>>> I think it is about time to start thinking seriously
>>> about moving data values out of existing xsd:documentation
>>> and into xsd:appinfo.
>>> I understand during yesterday's LC call that FP's
>>> code list team is looking into where to store their
>>> metadata, and an outcome will "decide" to some extent
>>> where the values go.  But I also understand that FP's
>>> set of metadata relates to presentational metadata,
>>> whereas existing <ccts:Component> data values relate
>>> to modeling and object class metadata.   Both are
>>> metadata (and so are data instead of documentation),
>>> but used at different times in different areas.
>>> It is a stated guide for UBL to follow recommendations
>>> and usage guidelines from W3C.  And XML Schema's
>>> xsd:appinfo is created precisely for the purpose of
>>> storing data that usually machines/apps would need,
>>> thus "appinfo".  Why are we choosing to be the odd one
>>> out by storing data into "documentation" instead?
>>> I earlier heard some summarised points of arguments
>>> supporting the storage of data values in "documentation"
>>> for some security reasons.  I could have heard wrongly,
>>> but security was quoted as the reason, that storing
>>> data in "documentation" is "safer" than storing data
>>> in "appinfo".   I'd like to suggest that we don't lose
>>> focus on the proper usage of the "appinfo" mechanism
>>> over reasons that are not going to be solved by moving
>>> to "doucmentation" anyway.
>>> This is by no means to say that security is not an issue,
>>> but rather, a debate over security safety levels between
>>> "documentation" and "appinfo" is really an XML Schema
>>> specification issue that is not going to reach any
>>> resolution within UBL.  And as long as we say we should
>>> follow W3C recommendations, application info ought to
>>> go into "appinfo";  I didn't see any debate being even
>>> necessary here, but perhaps on how the structure of elements
>>> should look within "appinfo".
>>> So, I'd like to hear if there's any further counter-remarks,
>>> or remarks on other perspectives that are in favor of
>>> data being stored in "documentation".  Please raise them
>>> soon.  I've made replies go to FPSC list since that's
>>> where the code list discussion on where presentational metadata
>>> should go is happening.
>>> Thanks.
>>> Best Regards,
>>> Chin Chee-Kai
>>> SoftML
>>> Tel: +65-6820-2979
>>> Fax: +65-6743-7875
>>> Email: cheekai@SoftML.Net
>>> http://SoftML.Net/
>>> To unsubscribe from this list, go to http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc. Note:unsubscribing will result in your withdrawal from this OASIS Technical Committee.
>>Eduardo Gutentag               |         e-mail: eduardo.gutentag@Sun.COM
>>Web Technologies and Standards |         Phone:  +1 510 550 4616 x31442
>>Sun Microsystems Inc.          |
>>W3C AC Rep / OASIS BoD
>>To unsubscribe from this list, go to http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc. Note:unsubscribing will result in your withdrawal from this OASIS Technical Committee.

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