[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Discussion Topics Re-Revisited
Hi Betty: The example John gave was not meant to be a complete ebXML message, only to raise a point of conversation regarding each element having a way to point back to a repository Data Element. We would not do this in the XML document instance, it would be done within the accompanying DTD or possibly Schema. I think that using the namespcaes such as your example is certainly alot more robust. We haven't yet decided an the actual syntactical (spelling?) method yet. >I don't think I understand the rationale for a unique ID for each >element type and not the content. By virtue of the unique name >each element is unique. What John was striving at is that each element will have a way to reference, via a unique ID, an XML file in a repository which caontains all the pertinant metadata about that element. >If it is, I understand the rationale for this approach. However, >I would argue against using an XML ID for this methodology. Also, >it wouldn't pass a parse for a unique ID. Becuase the attribute "ID" has special meaning and constraints within the XML 1.0 specification, I would not use that specific attribute name. The spec aslo states that the values of type ID must match the Name production and a name must not appear more than once in an XML document as a value of this type. ID values are used to uniquely identify the elements which bear them but were not intended to be used as a pointer. >If I were looking for a <FRUIT> and I don't know what the fruit >is but I have use the Unique ID in XPATH, I would get the first >food - which may be spinach. Unless you try: //FRUIT/FOOD[5] or use some other XQL statement. Nevertheless, we would not use the ID as demonstrated. The real question I think is "Should empty elements within the ebXML infrastructure be required to always reference a repository item?" I think that each DTD should be required to do so. There may be a business methodology rule whereby an item is required to be returned if it does not contain a certain default base set of elements, regardless of whether they contains text nodes. The ebXML application which will call upon the repository functionality may have rules to recognize this in order to avoid unnecessary querying. My $0.02 worth Duane Nickull ************************************* President, Software Systems Architect XML Global Technologies, Inc. http://www.xmlglobal.com *************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC