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: RE: [ubl-ndrsc] More comments on Tag Structure paper


Title: RE: [ubl-ndrsc] More comments on Tag Structure paper

Sorry for not participating in this thread sooner, but client workload is intense right now.  I have read the arguments of Dave and Mike and Eduardo, and agree that what they are saying can make sense from a single document development structure. The examples they provide are simple and straight forward, and certainly convey an argument for their approach.  We all understand that Schemas certainly support relying on hierarchical structure of the document to impart knowledge about the data.  {Of course traditional EDI also relies on hierarchical structure to impart metadata information). 

However, I still have significant concerns on adopting this semi structured approach from a standards development perspective.  It seems to me that relying on the Document and/or XSD hierarchical structure to impart additional and necessary metadata to our data adds another layer that only works when the document/XSD remains intact and becomes increasingly more complex as the document grows in size or relationship to other documents.  Will this always be the case?  What impact will optionality of individual parent/child tags have?  Is there an impact wrt the use of  XLink and XPointer?  What about Fragments? What about relationships between our dictionary and our tags?  Does this approach really mean that we are building a vocabulary? Is it really providing self describing data?

What about processing?  According to Professional XML Schema's, relying on the hierarchical structure puts an extra burden on the application working with the document.  in that it must retain the context of the name in memory in order to distinguish it. To Quote -

"If we were using SAX to read the document with overloaded names, our application would have to remember the context of the item in order to determine the meaning.  Alternatively, if we were using the DOM with methods such as getElementsByTagName( ), we would have to navigate to an appropriate node before we could use it."

I would also argue that this requirement to retain context applies to human readers as well.  As we develop complex documents, do we really want to require folks.

Seems to me we are trying to take advantage of a feature that works in a single document but does not work well across documents.  In building a suite of documents, we should be searching for consistency.  Structured tags afford us a way to achieve this much better than relying on the order or manner in which the tags are presented.  Especially since the data may appear in different orders or used in different parents within and across documents.  Structured tags also give us a consistent vocabulary, which I thought was one of our primary deliverables.

Mark

 



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


Powered by eList eXpress LLC