XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Help with XML anti pattern

Firstly, it you're going to do it as name-value pairs, I would definitely add an enclosing element:

<NameValuePair>
   <Name>xx</Name>
   <Value>vv</Value>
</NameValuePair>

because that makes processing much easier using almost any XML technology (whether XPath, data binding, or whatever).

I would probably use attributes rather than child elements, but that's a pretty low-level difference.

You're right, of course, that at one level this is technical nonsense: XML is already extensible at the level of element names, so what does this additional layer of extensibility add?

In practice, though, systems impose rules on the element name vocabulary, whether through schemas, data binding, or whatever, that make it difficult to exploit XML's intrinsic flexibility to add new elements. So changing the vocabulary at the level of element names isn't always as easy as it might be, which is why people feel a need to add another layer.

I remember being taught as a student (by Roger Needham, I think) that most problems in computing can be solved by adding another level of indirection.

Michael Kay
Saxonica

On 23 Nov 2021, at 18:49, Ihe Onwuka <ihe.onwuka@gmail.com> wrote:

If you made FirstName, LastName and SWName attributes of SWMakerInfo wouldn't that satisfy both parties.

On Tue, Nov 23, 2021 at 1:21 PM William David Velasquez <wd@creativosdigitales.co> wrote:

Hi XML folks,

I want to share here a real case to ask for your wisdom and advice:

This week my company started to work in a project involving a customization of UBL Invoices. A team before us, defined a structure similar to this for receiving the name of a person and the name of a software product:

<ext:UBLExtension>
  <ext:ExtensionContent>
   <SWMaker>
    <SWMakerInfo>
      <Name>FirstName</Name>
      <Value>Erick</Value>
      <Name>LastName</Name>
      <Value>Rich</Value>
      <Name>SWName</Name>
      <Value>FancySoft v.1.0</Value>
    </SWMakerInfo>
  </SWMaker>
 </ext:ExtensionContent>
</ext:UBLExtension>

This way of modeling data is opposite to the essence of XML, but frequently used by programmers that sells it as "flexible" because it can accommodate future uses with new combinations for elements "Name" and "Value" (and because many programming languages translate object dictionaries to this kind of XML).

The problem arrives when XPath expressions become more complex (although not impossible to write) to access data:

For example, to get the first name:

ext:UBLExtension/*:ExtensionContent/SWMaker/SWMakerInfo/Name[ . = "FirstName" ]/following-sibling::Value[1]

But this kind of expression is not trustworthy. For example, if the first <Value> element is missing, the LastName will be returned instead.

I'm asking for your help, because we'll have a meeting with the contractor and I need arguments to convince them of changing to a
"Natural" XML structure like this:

<SWMaker>
  <SWMakerInfo>
    <FirstName>Erick</FirstName>
    <LastName>Rich</LastName>
    <SWName>FancySoft v.1.0</SWName>
  </SWMakerInfo>
</SWMaker>


I'm expecting customer won't be open to accept the change, because the actual structure can do the work.

So, what arguments would you use to convince the customer?

Thanks in advance for all your input. It is very enriching to read your opinions and learn from all your experience.

 

-- 
William David Velasquez
Creativo de Software
Creativos Digitales S.A.S.




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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS