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: Formal public comment: Scott

We are in receipt of the following public comment, which should be
added to the issues list by the NDR team.




Date: Wed, 22 Mar 2006 16:01:16 +0000
From: comment-form@oasis-open.org
Subject: [ubl-comment] Public Comment
To: ubl-comment@lists.oasis-open.org

Comment from: dms@haplos.com

Name: Dave Scott
Title: President
Organization: Haplos, Inc.
Regarding Specification:  UBL NDR

Rule ATD1 prohibits the use of user-defined attributes,
effectively limiting the use of attributes in an NDR-compliant
schema to CCT meta-data.  I understand this restriction as an
attempt to maximize the extensibility of NDR-compliant schema.
However, this restriction has an adverse affect on
stream-processing of very large documents that I have not seen
mentioned in discussions of the rule.  Generic XML
stream-processing tools usually cache only the ancestor relations
-- the current node stack -- for use in determining processing
conditions.  To follow the NDR, attributes that are often used as
processing 'switches' ('type', 'role', 'method', ...) must be
moved down in the hierarchy to become child nodes.  This makes it
impossible to use the stack-state-only tools, forcing developers
to write custom SAX handlers to stream process documents.  In
addition, the only way to avoid caching all the children during
stream processing is to add ordering constraints that forces the
'switches' to appear first amongst the children.  Introducing
schema constraints which do not have a semantic justification is
not a good practice.

I understand that rule ATD1 is making a trade-off.  But I think it
gives away too much.  Following the NDR, (1) I lose the ability to
use attributes to capture the intended semantics of my model
(especially attributes that have a scoping function.)  And, more
importantly, (2) I lose the ability to use generic XML stream
processing tools to efficiently handle large documents.

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